Re: Possible break-in attempt?
Dimitry Andric wrote: > For each incoming IP address, sshd does a reverse lookup, and if that > results in a hostname, it does another lookup of that hostname, to see > if *that* result matches the original incoming IP address. If it does > not, you get this scary warning in syslog about a "possible break-in > attempt!". > > In my opinion, this is fairly misleading, since almost always the actual > cause is badly configured DNS, a very common occurrence. In addition, > matching forward and reverse DNS records is no guarantee at all that the > incoming IP address is in any way trustworthy. I'm not sure which version this made it into, but they actually removed this over 2 years ago. It's not in the openssh that ships with FreeBSD 11.2: | commit e690fe85750e93fca1fb7c7c8587d4130a4f7aba | Author: dtuc...@openbsd.org | Date: Wed Jun 15 00:40:40 2016 + | | upstream commit | | Remove "POSSIBLE BREAK-IN ATTEMPT!" from log message | about forward and reverse DNS not matching. We haven't supported IP-based | auth methods for a very long time so it's now misleading. part of bz#2585, | ok markus@ | | Upstream-ID: 5565ef0ee0599b27f0bd1d3bb1f8a323d8274e29 cheers, Jamie ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http subversion URLs should be discontinued in favor of https URLs
Gordon Tetlow wrote: > I want to move the default for svn to be HTTPS. This would mean setting > up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For Blimey! You're either very brave, or haven't read the thread fully! :-) ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http subversion URLs should be discontinued in favor of https URLs
Matthew Finkel wrote: > Why doesn't everyone have that option? Why is broadcasting a users information > across the internet forced upon them? Shouldn't they have a choice? They do! HTTPS already exists! This thread is about removing HTTP and forcing HTTPS - "Why should HTTPS be forced upon them? Shouldn't they have a choice?" :-) | 21:16 (4) "/tmp" root@lapcat# svn export https://svn.freebsd.org/base/stable/11/usr.bin/fortune | Afortune | Afortune/datfiles | | [ ... ] | | Afortune/tools/Troff.sed | Exported revision 326782. Voila! A https delivery of "fortune" ! (Confirmed via tcpdump not to be using fallback HTTP) cheers! ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http subversion URLs should be discontinued in favor of https URLs
John-Mark Gurney wrote: > So you're fine w/ all the Comcast users having to switch ISPs? Because > Comcast modifies traffic. So you're now saying that if you use FreeBSD > you can't use Comcast as your ISP? ... or they could use HTTPS, which exists. This thread started with the proposal to remove HTTP, nothing to do with disabling already existing HTTPS solutions. Cheers, J. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http subversion URLs should be discontinued in favor of https URLs
"Poul-Henning Kamp" wrote: > simple-minded IT-liberalistic "Encrypt everything" campaign is, > 100% as predicted, pushing governments to neuter encryption in > order to keep the court systems working. I agree. Unfortunately forums.freebsd.org not only went down the 'encrypt everything' route, they did so before TLS was ubiquitous (disabling SSL2 & SSL3 way before most places) Not directed personally at you, phk - it's just strange that forum questions are considered more important to secure than source files! cheers, Jamie ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ntpd vulnerabilities
Brett Glass wrote:
> Within my own network, I have used cron and ntpdate (even though it's
> officially deprecated) on most of the clients, querying a couple of
I think ntpdate is only deprecated because it's functionality is provided
by 'ntpd -q'
> on them. But it obviously has some drawbacks; in particular, it doesn't
> continuously correct the clocks but makes them jump at particular
> times of day.
Until recently, I'd been using this too, however, using the '-B' option to
ntpdate ('-x' to nptd) to slew the clock instead. A couple of these a day in
cron causes neglegable drift, unless your clock ain't too good!
Cheers, Jamie
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Potential security issues with new top level domains?
As if I needed another reason to hate the new top level domain free-for-all, I was checking on one of my machines earlier, and forgot that I'd renamed it, so it is no longer in my domains DNS. This was the result: | 2:13 (2) "~" jamie@catflap% ping android | PING android (127.0.53.53): 56 data bytes | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ^C | --- android ping statistics --- | 3 packets transmitted, 0 packets received, 100.0% packet loss | | 2:13 (3) "~" jamie@catflap% cat /etc/resolv.conf | domain dyslexicfish.net | nameserver 127.0.0.1 | options edns0 A quick check revealed that, as expected, unbound was first asked for 'android.dyslexicfish.net.' which returned NX, and was then asked for 'android.' which resolved the 'A' that the owners of the TLD have configured. Now, any scripts/binaries etc. I have that use DNS resolution always use the FQDN with the trailing dot, so I have no personal security worries, but I'm sure there are others out there that don't, and even so, it could still bite for interactive use. Yes, the 'A' returned is invalid in this case, but what's to say this will be the case with all future new TLDs? I realise the spec is being followed correctly, but it still seems wrong to me that any 'host' related resource types resolve for an address at the top level, and I was wondering what others thought about it? Should the FreeBSD resolver ignore / not make such requests? Should instead the functionality be built into unbound/named etc.? Should instead TLD owners be banned from adding such records? (this still could be abused though) Should neither be done? I dunno, I'm just used to A/ resolves on a non qualified address to either come from /etc/hosts, or be in under a domain in 'domain/search' from /etc/resolv.conf The current situation seems 'wrong' and potentially troublesome to me, but I'd be interested in what others think. Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: NEVERMIND!
I've not actually used it, but I notice this in ports: /usr/ports/sysutils/socklog: | svlogd has a built in log file rotation based on file size, so there is no | need for any cron jobs or similar to rotate the logs. Log partitions can be | calculated properly. | | WWW: http://smarden.org/socklog/ Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ports requiring OpenSSL not honouring OpenSSL from ports
Paul Hoffman wrote: > Yes, that is a reasonable expectation. I certainly had it in my head when I > rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it. Been there :-) Fortunately, sendmail 'does the right thing'! > It would be good to add such options to as many ports as possible if it can > be done cleanly. This is more for ports@ than security@, but isn't mixing of 2 different versions potentially problematic? I have noticed one port that links against base, but uses libcurl which links against ports, so there is a version conflict there right away. I'd expect that some magic would need to be done in the bsd.ports.Mk files, as you can't necessarily tell from just scanning the port template. > Also, note that this is not bashing on OpenSSL: given their new significant > funding, I would certainly expect the OpenSSL project to be > finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It > is basically impossible to fix such a bug without bad actors being able to > determine and exploit some of the fixes in unpatched systems. Ditto. My concern is more general, and aligned to the POLA principle! Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ports requiring OpenSSL not honouring OpenSSL from ports
Scot Hetzel wrote:
> The port should use the OpenSSL port if it is installed, unless the
> port sets one of these variables in it's Makefile:
>
> WITH_OPENSSL_BASE
> USE_OPENSSL_BASE
>
> The port shouldn't be setting these variables.
Thanks. As I expected.
> Do you have a list of which ports used the OpenSSL from base, instead
> of the installed OpenSSL port?
> Could you check if they set these variables.
Well, I can only check the ones I have installed. Here's a list of some
that link against /lib/libcrypto.so.7 and/or /lib/libssl.so.7 retrieved
using the following command:
# grep -EaHlr -D skip 'libssl\.so\.7|libcrypto\.so\.7' /usr/local | awk '{print
"pkg which -oq " $1}' | sh | sort | uniq
[ N.B. 'grep -r' follows symlinks. You'd need to use 'find ... | grep ...'
instead to be more bulletproof ]
devel/android-tools-adb
net-p2p/transmission-cli
net-p2p/transmission-daemon
net/socat
net/svnup
ports-mgmt/pkg
security/john
security/scrypt
security/trousers
sysutils/tarsnap
Again, as expected, none of these contain references to WITH_OPENSSL_BASE or
USE_OPENSSL_BASE, though I do get some ld conflict warnings in some cases
(e.g. when linking to libcurl, which does do the right thing)
> This is more of a ports issue, than a security issue.
>
> Post the list of affected ports to ports@, and/or submit PRs to
> correct the them.
I wanted to discuss the issue and make aware the security community
before discussing actual changes with @ports
As I said. there could be security implications if someone thinks a
patched previously vulnerable openssl port has secured all of their
other ports.
Also, it's not reliably possible to check which ports are affected
without at least downloading the distfile - some of the ports make no
reference to ssl in their ports template.
Cheers, Jamie
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
ports requiring OpenSSL not honouring OpenSSL from ports
One of the first things I do on installing a new machine is install OpenSSL from ports. I do build with base OpenSSL due to the many programs that depend on it, but using ports OpenSSL for ports makes things easier to patch/update. In the case of Heartbleed, for example, I was able to fix ports OpenSSL much sooner than base. In the process, however, I discovered a couple of ports that built against base even when the port was installed. I was going to supply patches / notify the maintainers, but first did a check, and discovered that a lot of current ports do similar. It turns out that this wasn't a problem specifically, but more generally, it's possible that someone may think a port has been patched when it hasn't. Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* build against the port if it's installed? I realise this isn't always possible to test, especially if the port Makefile doesn't have any openSSL configuration options, but I'd like to hear others opinions on the matter. [ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte, but feel free to add them in if appropriate ] Cheers, Jamie -- No sig ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
"hcoin" wrote: > local variables) harms performance. It's also true doing both of these > things would not fix the flaw that 'opened the window' onto these data. > However it is true that doing so would make the exploit valueless as > 'opening a window' onto erased data would reveal nothing and could erase > trojan/virus 'hijack via code-injection then trampoline' opportunities. In the heartbleed case, was the bug returning stale freed memory, though? Couldn't it just as easily have been that the over-read was returning any other memory that the process has had allocated for other variables - data that was still in use? > If the variable stack and free() functions erased data spaces, there > would be no security value in having application edge malloc effectively > be calloc. Yeah. I had wrongly assumed that this was a throwback to more innocent days, and that these days, malloced space was effectively cleared by every sane OS, but due to backwards compatibility, the spec only defines calloc as acually clearing data, so you should never assume malloced memory was cleared, even though effectively it is these days. But Nathan and RW helpfully showed me where my reasoning failed! > There may be marginal security value in having OS edge free() erase data > before subsequent OS edge malloc of the same page to a process owed by a > different userid. Now this I don't get. Marginal? Surely in this case, this is a MUST. Otherwise we'd continually be getting local users getting data they shouldn't Every machine would be a 'heartbleed' for local users, even when running bug free code! I'd even extend this policy to different processes - even with the same id, because, of course, many daemons spawn children that deal with different connections simultaneously. (But of course in this case any leak would be down to bad programming if data leaks were discovered to be exploitable.) But yeah, surely if the UID (or more accurately, the EUID) were different but the data wasn't erased by the system prior to malloc, a leak would be unpreventable (unless, of course, the careful programmer never frees data, until he/she has erased it themselves beforehand. And who does that? > This entire discussion, (clear-on-free and > clear-stack-on-function-return) are resource heavy ways of managing > complexity. It is for the community to decide whether it is 'worth it' > on a case by case basis given there is no way to prove a program > 'correct' from a security perspective. I agree. More generally, all exploit busting mechanisms add to complexity and resources, whether it's DNS randomizing outgoing udp ports, or stack protection/pro police/canaries etc. You have to make a judgement call based between the protection of your software against speed, throwing into the equation the competence of your programming team! cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
RW wrote: > It can return the physical memory, but there are a couple of caveats. > Firstly, it can only return whole pages. Secondly, it's not returned > instantaneously to avoid the overhead of page-faults and zeroing pages > if that region is remalloced. It's left to the page-daemon to recover > the physical memory in its own time, and it remains readable by it's > previous process until it's reassigned. Again, thanks for clearing that up for me. I wasn't all that far off-base after all, but yours and Nathans replies make sense! So there is a real world use for calloc after all! (though only as a bug catching security measure - no sane program should ever read its memory it hasn't yet written to!) cheers, jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
Nathan Dorfman wrote: > free() doesn't usually "free memory back to the system." It just puts > it back onto a "free list" managed by libc, entirely within the > process's address space. > > "Use after free" is actually a rather common type of bug -- do a web > search on that term to see just how often it comes up. Ahhh, so (simplifying it here somewhat), malloc/free don't always affect the kernels own representation of the processes memory allocation, as part of libc behaves a bit like a cache - buffering and managing requests in userspace, so as to make things run more efficiently. Thanks for the reply - my question wasn't quite as stupid as I feared! Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
> I wonder how many security holes, both those known and as yet unrevealed > or unknown, would not be of any exploit value if in all security related > libraries and applications the routine to free allocated memory > allocation closest to the user app/library set the newly free memory to > a known pattern or something from /dev/random before returning. And, > similarly, a compiler option causing function returns using more than a > few dozen bytes of stack space to erase the newly freed stack region I'm probably being really dense here, and realise I can't delete this post once sent! But Once memory has been freed, I thought any attempt by a user process to access it would cause a SIGSEV. I thought the issue was with programs that inadvertantly expose (either to read or write) other parts of their active memory. Of course, if a process rolls it's own in-process implementation of malloc/free, then this point is moot, but once you free memory back to the system, isn't in no longer accessable anyway? Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
Bryan Drewery wrote: > On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: > > > > As to the specific question, I don't think his ego would allow a bug > > in openssh to persist, so even if it does, I'd suspect it's not too > > serious (or it's non-trivial to exploit), and it's related to FreeBSD > > produced 'glue'. > > > > This is total guesswork on my part, but I'd therefore assume he was > > talkining about openssh in base, rarther than openssh-portable in > > ports. > > > > As the maintainer of the port I will say that your security decreases > with each OPTION/patch you apply. I really would not be surprised if one > of the optional patches available in the port had issues. A. good point. I forgot about third-party patches. Yeah, if he's not just blowing smoke, that would make the most sense. I don't reckon he'd leave an exploit open if it was purely related to the unpatched source - even if there is some quirk which only makes it only applicable to FreeBSD. Still, by not revealing it, he's only potentially hurting the users. I wonder how many blackhats are going to use this thread as a heads-up? Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: De Raadt + FBSD + OpenSSH + hole?
Matt Dawson wrote: > My first thought when I saw this was "ego over ethics," which says more > about Theo than FreeBSD. Totally. I know Theo has a reputation for being 'difficult', but in my opinion, this outburst really calls into question his perceived motivations regarding secure software. As to the specific question, I don't think his ego would allow a bug in openssh to persist, so even if it does, I'd suspect it's not too serious (or it's non-trivial to exploit), and it's related to FreeBSD produced 'glue'. This is total guesswork on my part, but I'd therefore assume he was talkining about openssh in base, rarther than openssh-portable in ports. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ftpd security issue ?
> > Are the following steps enough to prevent me? > > > > # for user in user1 user2 ; do > > mkdir -p ~$user/lib ~$user/usr/lib ~$user/etc > > chflags sunlink,schg ~$user/lib ~$user/usr ~$user/usr/lib ~$user/etc > > done > > # > > Yes that should be sufficient workaround. I'd modify that to also check that the directories don't already exist, and delete/rename them if they do. Currently, (if you ignore error messages) your script will not fix users who already potentially exploit the issue. Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> +1 I did mention the bikeshed earlier ! :D ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> It is still required for .. to work. > > For example, if the /usr directory on / is 700 but the directory on the > mounted filesystem is 755, everyone can use pathnames under /usr but only > root can use /usr/.. which is confusing and undesirable. > > > I always make mount-points 0111 these days > > I'd recommend to keep doing that :) Wow! Good catch! I missed that! And I note that ".." doesn't even appear on an ls -a That tells you too, Chris Rees :-) Ok, I'll stick with 0111 - also, the reason I use 0111 instead of just the default 755 (or whatever) is that it's an alert to me if some mount isn't mounted for whatever reason. To me, 0111 means mount-point only, period. Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> Dumb question: the jail command can refuse to run unless the > parent of a jail root is 0700. Would that work? No kernel hack > required. Haha, all talking about kernel hacks and so on, and yet, to me, that seems the simplest, but ALSO, the most elegent solution. I'd have some override flag that could be set for those who's jails are directly under an important folder, e.g. /usr/my-jail-name/ so that those unable to change straight away can set an rc/sysctl flag rather than have to hack the code.. Is this turning into a bikeshed discussion? ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> Why not ? What sense does having -r+x make? Because on some old systems I used to work with, you needed +x for it to work. Now I know works on FreeBSD, I'll try to remember to use that instead! ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> It used to confuzzle sysadmins on SUNos when the mount point was > 0700. The underlying mode disapeared when the mount was made, but it > was still being enforced. Suddenly no one but root could use say /usr > even though it was apparently 0755 I remember that happening! I thought it was like that on FreeBSD too, but if it was, it isn't any longer! I always make mount-points 0111 these days ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)
> Do you know if there is a way that chmod on / from within the jail could > be prevented easily without breaking something ? Maybe not failing but > falling though and return 0 for any operation with the sole argument of /. Enforcing 700 on the jail root? Whilst I was wrong on chmod 700 on (say) /usr/jails it is still the case that the root directory of the jail itself (/usr/jail/jailname) has to be 755 for non-root processeses within the jail to access the filesystem! cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P�tur)
> > A jail won't work for not-root users if the jail root directory is chmod > > 700 - although > > there is obviously a 'chroot' running withing the jail, the jailed user > > still needs > > to have read permission from the hosts / -- chmod 700 therefore locks all > > non-root > > users out. > > > > It's weird - I don't remember having such problem after setting jails' > root directory permission to 700. I don't have the system anymore so I > can't verify it just yet. I just tried it again (Freebsd 8.2) and I am wrong. Setting 700 on the jail root does indeed mess things up. But setting it on the parent (e.g. /usr/jails), and things are fine. Stupidly of me, that makes perfect sense. The non-privileged user needs read access to the jails "/" Sorry for the spam ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Rooting FreeBSD , Privilege Escalation using Jails (P�tur)
> All the same, I've sent a PR [1] with some doc patches to make people > more aware of this -- fulfilling my promise of 2+ years ago :S > > Thanks! > > Chris > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=156853 Um. Some problems here. A jail won't work for not-root users if the jail root directory is chmod 700 - although there is obviously a 'chroot' running withing the jail, the jailed user still needs to have read permission from the hosts / -- chmod 700 therefore locks all non-root users out. I would suggest you add to the docs about the UID clash problem - untrusted users on the host shouldn't have the same UID/GID as jailed users, as they will have access to their files. And of course, the bit mentioned earlier where an untrusted jail user with jail-root access should NEVER have access to the host!o Among other things, my password file in both jails and the host has this line: # 8000 to - Reserved for use within jails - do not use in main host! cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: mbuf security advisory for 7.2-RELEASE?
> >> Just to confirm, 7.2-RELEASE is not effected by this issue? Just > >> seems odd that all versions of 7.x are listed minus 7.2-RELEASE. > > > > 7.2-RELEASE was out of support when the advisory was issued. > > It *is* vulnerable. > > Thought so! Thanks guys! It just wasn't clear to me. Easy mistake to make, seeing as 7.1 is not EoL, but 7.2 is! ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> Any body can explain why no credit section for this advisory? Probably because the person who found the bug didn't notify the security team, but posted it on a public list to gain l33t points. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> > On 12/03/2009 08:01 PM, Pieter de Boer wrote: > > Jamie Landeg Jones wrote: > >> > >> However, I'd still apply the patch in case some other way to exploit > >> the non-checking of the unsetenv return status crops up elsewhere. > >> > >> It can't do any harm. > > > > The problem with that is, on 6.x, unsetenv() returns 'void', so there's > > no return value to check on. As Pieter pointed out, unsetenv returns 'void', so checking for a return value (like that patch does) doesn't make sense. Sorry for wasting your time - the patch is not necessary (and won't even work) on 6.X systems, as you've discovered. Your system is safe from this attack, and any related ones. Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> The discussion you mention presumably involves checking out the patched > version of rtld sources from 7.x or 8 and building+installing that under 6.x. > Given that 6.x rtld is the older one with a longer history of security > review and doesn't have the current known vulnerability, whereas the new > version just got patched and might have other issues lurking, I am happy > sticking with 6.x version on my 6.x boxes. A, I see. I was looking at the source of rtld.c to check when the change was made that allowed this vulnerability to exist, and that change was from 6.3 onwards. But it seems it's the changes to getenv/unsetenv from 7.0 onwards that cause this to be an exploitable issue. However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> So, what would be 'best of practice' to apply the patch to 6.3-RELEASE > upwards -- is the FreeBSD-7 patch applicable or should one wait for an > official announcement? I just noticed that the patch I replied with is basically the same as the Freebsd-7 patch that was posted. However, as has already been discussed, 6.X isn't exploitable by the posted bug, because the changes to the env functions that allow the exploit to work didn't happen until 7.X However, I would certainly apply the patch anyway - basically, the old way was just blindly unsetting environment variables and blindly assuming the unsetting worked. The new way does exactly the same unsetting, but if any of the unsets fails (due to corrupt environment) it aborts. Just in case there is some other way of exploiting the fact that rtld.c didn't check whether unsetenv was successful (which I bet people are now looking for) I'd apply the patch to 6.3 and 6.4 also, just to be sure. Cheers, Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> Jamie Landeg Jones ha scritto:
>
> > So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't.
>
> Thanks.
> So, is a patch on the way for 6.[34] too?
> I guess the sec team just wanted to get out what they had as soon as
> possible and I agree with them and thanks them.
> But I just need to plan... :-)
I don't know - are they still supported?
Anyway, I just made this patch. I don't have any 6.X machines to test it on,
but it should work on 6.3 and 6.4 (put it this way, if it doesn't work it
will fail to compile, rather than break your machine!):
Incidently, I am not part of the offical freebsd team.
cheers,
Jamie
--- rtld.c.orig 2007-07-14 20:04:00.0 +0100
+++ rtld.c 2009-12-03 17:29:58.0 +
@@ -349,11 +349,12 @@
* future processes to honor the potentially un-safe variables.
*/
if (!trust) {
-unsetenv(LD_ "PRELOAD");
-unsetenv(LD_ "LIBMAP");
-unsetenv(LD_ "LIBRARY_PATH");
-unsetenv(LD_ "LIBMAP_DISABLE");
-unsetenv(LD_ "DEBUG");
+if (unsetenv(LD_ "PRELOAD") || unsetenv(LD_ "LIBMAP") ||
+ unsetenv(LD_ "LIBRARY_PATH") || unsetenv(LD_ "LIBMAP_DISABLE") ||
+ unsetenv(LD_ "DEBUG")) {
+ _rtld_error("environment corrupt; aborting");
+ die();
+ }
}
ld_debug = getenv(LD_ "DEBUG");
libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL;
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
> Sorry, this might seem a stupid question, but... > In several places I read that FreeBSD 6.x is NOT affected; however, I > heard some people discussing how to apply the patch to such systems. > So, I'd like to know for sure: is 6.x affected? Is another patch on the > way for it? > > bye & Thanks > av. The change that introduced the bug was made as follows: | Revision 1.124: download - view: text, markup, annotated - select for diffs | Thu May 17 18:00:27 2007 UTC (2 years, 6 months ago) by csjp | Branches: MAIN | CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 | Branch point for: RELENG_7 | Diff to: previous 1.123: preferred, colored | Changes since revision 1.123: +20 -10 lines | | In the event a process is tainted (setuid/setgid binaries), un-set any | potentially dangerous environment variables all together. It should be | noted that the run-time linker will not honnor these environment variables | if the process is tainted currently. However, once a child of the tainted | process calls setuid(2), it's status as being tainted (as defined by | issetugid(2)) will be removed. This could be problematic because | subsequent activations of the run-time linker could honnor these | dangerous variables. | | This is more of an anti foot-shot mechanism, there is nothing I am | aware of in base that does this, however there may be third party | utilities which do, and there is no real negative impact of clearing | these environment variables. | | Discussed on:secteam | Reviewed by: cperciva | PR: kern/109836 | MFC after: 2 weeks This was also ported MFC'd into 6.3 onwards: | Revision 1.106.2.7: download - view: text, markup, annotated - select for diffs | Sat Jul 14 19:04:00 2007 UTC (2 years, 4 months ago) by csjp | Branches: RELENG_6 | CVS tags: RELENG_6_4_BP, RELENG_6_3_BP, RELENG_6_3_0_RELEASE, RELENG_6_3 | Branch point for: RELENG_6_4 | Diff to: previous 1.106.2.6: preferred, colored; branchpoint 1.106: preferred, colored; next MAIN 1.107: preferred, colored | Changes since revision 1.106.2.6: +20 -10 lines | | MFC rtld.c revision 1.124 | | Unset potentially harmful environment variables. | | Discussed on:seacteam | PR: kern/109836 So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
