Re: Re: Hardened OpenSSL fork
On Tue, 29 Apr 2014, Steven Chamberlain wrote: On Mon, 28 Apr 2014 16:52:10 + (UTC), daThorsten Glaser wrote: For their OpenSSL fork, specifically, they rely on some system properties such as their RNG’s behaviour way too much [...] I would think Linux and FreeBSD have much better PRNGs now than what has been done until now in OpenSSL. No, not exactly. Linux’ /dev/urandom is way too small, it has only 512 bits of state, which makes all sorts of people object to code reading more than 8/16 or at best 32 bytes out of it for any given application. not trustworthy, OpenSSL is resorting to mixing in uninitialised blocks of memory, the time, private key exponents, digests, in one case a structure returned by stat() It also adds 32 bytes from /dev/urandom (see #742145 where I find that a bit few, but given the above it’s reasonable), and from ~/.rnd or another randfile (not any more in LibreSSL). bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1404301434500.12...@tglase.lan.tarent.de
Re: Hardened OpenSSL fork
On 04/21/2014 02:07 AM, Steven Chamberlain wrote: OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g I'm not so sure if cleaning-up really means removing 90k lines of code without extensive checks. I'd very much prefer some unit tests added to the current code base, or a *long* audit process for example. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535f6937.8020...@debian.org
Re: Hardened OpenSSL fork
previously on this list Thomas Goirand contributed: OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g I'm not so sure if cleaning-up really means removing 90k lines of code without extensive checks. I'd very much prefer some unit tests added to the current code base, or a *long* audit process for example. I understand the concern over reliability in the short term but they are not playing and quite frankly in light of heartbleed any issues that align with 99% of use cases can be fixed and I don't think that has anything to do with the OPs thread. If it does what 99% need (you should test in any case) and has 90k less lines of code then the rest can be better audited and if better understood then it is more likely to work especially in the long term, it is not part of OpenBSD stable yet. I guess you haven't witnessed all the examples of code rot and worse that they have found? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/930532.18175...@smtp112.mail.ir2.yahoo.com
Re: Re: Hardened OpenSSL fork
On Mon, 28 Apr 2014 16:52:10 + (UTC), daThorsten Glaser wrote: For their OpenSSL fork, specifically, they rely on some system properties such as their RNG’s behaviour way too much [...] I would think Linux and FreeBSD have much better PRNGs now than what has been done until now in OpenSSL. In case seeding from /dev/urandom is not trustworthy, OpenSSL is resorting to mixing in uninitialised blocks of memory, the time, private key exponents, digests, in one case a structure returned by stat() If this had been overhauled earlier, the Debian OpenSSL bug might have never happened? (Use of uninitialised memory was causing valgrind warnings in applications using the library, and the mistake was made trying to work around that I think). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53602127.2020...@pyro.eu.org
Re: Hardened OpenSSL fork
Here's a good catch I think: http://freshbsd.org/commit/openbsd/b6c83fa20a2269dadd0a9a73049813c75c2bcbbb SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disables a workaround for the weakness described in https://www.openssl.org/~bodo/tls-cbc.txt which, I think, was exploited by the BEAST attack ~9 years later. Much software in Debian can be seen to use SSL_OP_ALL, which includes SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS which could disable that mitigation. This has been addressed in some Debian packages already, typically with = (~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS): https://security-tracker.debian.org/tracker/CVE-2011-3389 But it looks like some packages have perhaps not addressed this yet? From http://codesearch.debian.net/search?q=SSL_OP_ALL : neon27 nmap ruby1.8, ruby2.0 (possibly?) freerdp (perhaps necessary for compatiblity with some Windows versions?) cyrus-imapd-2.4 links2 w3m apache2 (mod_ssl) nginx stud postfix ...and many more. I wonder if a bug filing is sensible or if I missed something obvious. I'd like to establish exactly which SSL/TLS implementations are known to be incompatible with this workaround; I saw MSIE 6.0 mentioned somewhere. AIUI if using TLS =1.1 this is already mitigated. Breaking compatibility with Windows XP or MSIE 6.0 should be increasingly viable nowadays, if it improves security for the rest of us. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53602ab9.7050...@pyro.eu.org
Re: Hardened OpenSSL fork
Kurt Roeckx kurt at roeckx.be writes: On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. One of the problems with anything from OpenBSD is that they only care about OpenBSD, and if you want to use that fork you'll actually have to go and revert some of the things they're doing. Right. In some cases, the OpenBSD-caused cleanup helps though, although even for mksh’s predecessor, it also introduced bugs, and certainly made things unportable. For their OpenSSL fork, specifically, they rely on some system properties such as their RNG’s behaviour way too much (and even then, they lose out on some things… but that’d be more ontopic on a MirBSD mailing list). I think this will work out on neither Linux nor kFreeBSD nor Hurd port of Debian. Some of the things they're changing are actually good changes, but some are also just wrong. They don't seem to be understanding why things are the way they are and seem to be changing code they don't understand. Right. I saw a few of their changes which will turn out harmful, since I was deep in those very lines of code only 2-3 weeks prior. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? There are alternatives I find all of them questionable. OpenSSL is still the gold standard, sad as that may be. Let’s hope OpenSSL upstream devs wake up now. but I guess you mean alternative to openssl. Currently it actually doesn't look like a good option to me. Fully agreed. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140428t184835-...@post.gmane.org
Re: Hardened OpenSSL fork
Steven Chamberlain steven at pyro.eu.org writes: I'd say the code still looks quite 'portable' in that it is ANSI C and isn't using kernel-specific features. arc4random is just a library routine from their libc and I see no reason it can't be borrowed. No, it’s more. And after sysctl() got removed from Linux, the concept of arc4random is not applicable to Linux any more. Let alone Hurd. bye, //mirabilos PS: arc4random using RC4 can be made immune against all known attacks against RC4. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140428t190937-...@post.gmane.org
Re: Hardened OpenSSL fork
On Mon, Apr 21, 2014 at 02:38:52AM +0100, Steven Chamberlain wrote: They've ripped out this whole PRNG now to use the one from their own libc: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/rand/rand_lib.c.diff?r1=1.14;r2=1.15 And I think just a change like that might work on OpenBSD but will totally break security on all other OSes. OpenBSD documents that it will acutally regurally reseed it, and do so on fork(). There is no such documentation for Linux so I assume it doesn't. OpenBSD also replaced RC4 with ChaCha20, while Linux probably still uses RC4. We should stop using RC4. So this might be a good thing on OpenBSD, but it's not a good thing for something that needs to be portable. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421082106.ga31...@roeckx.be
Re: Hardened OpenSSL fork
On Mon, Apr 21, 2014 at 12:34:12AM +0100, Kevin Chadwick wrote: previously on this list people contributed: On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: Hi, But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. One of the problems with anything from OpenBSD is that they only care about OpenBSD, and if you want to use that fork you'll actually have to go and revert some of the things they're doing. Not true actually but of course their primary concern is naturally OpenBSD. They takes POSIX seriously and atleast one patch has brought it closer to POSIX standards. It is also clear to me that Theo wants all to follow and benefit from best practice and bug hunting, the fact that there is so much resistance is not his fault... is strlcpy still rejected by glibc on the false premise of not solving truncation despite better performance than strncpy and when it makes finding truncation much easier! when used how they have been applying it to openssl. https://lwn.net/Articles/507319/ I'm not sure what you're trying to say here. But look at the example of the random number generator in my other e-mail. I've seen other cases were they do things like that. And I can perfectly understand why they do it, and then rely on that behaviour on OpenBSD, but it only works on OpenBSD. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. This did not allow heartbleed to happen. It might have hidden CVE-2010-5298 more, but it was always there and is unrelated to heartbleed. It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided essentially for free. It seems you do not understand either vulnerability. - heartbleed: You send a packet and the other sides sends it back. Part of that packet contains a size which is not checked and that allows you to read more data than you send. If heartbleed wasn't been exploited there was no way to detect it. If it was being exploited, it can still go undetected assuming you limit the amount of data that you read. To be able to detect it with malloc() you probably need to give each malloc() it's own page and have a guard (before and) after it. - CVE-2010-5298: This has actually been reported 4 years ago already, long before heartbleed was introduced. This is a case where you call free() when you still have data, and you might have gotten that back in the next malloc(), or you might have gotton something else back. This is something that the native malloc() will probably have catched, but you see it with their implementation too. But this only happens when you turn on an option (not related to heartbleed) that not everybody uses and they most likely wouldn't have found this either. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421085535.ga32...@roeckx.be
Re: Hardened OpenSSL fork
On Mon, 21 Apr 2014 10:55:36 +0200 Kurt Roeckx wrote: I'm not sure what you're trying to say here. But look at the example of the random number generator in my other e-mail. I've seen other cases were they do things like that. And I can perfectly understand why they do it, and then rely on that behaviour on OpenBSD, but it only works on OpenBSD. It is a big task they are undertaking and are simply making their job easier. Later I expect portability patches can be more easily considered. I am sure OpenBSD get's far less funding than OpenSSL you know. I don't use debian online but if I did I would find an OpenSSL package with a dependence on haveged until something better is upstreamed desirable. I also expect patches may be needed or reverted for OpenBSD's long long time_t. http://www.openbsd.org/papers/eurobsdcon_2013_time_t/ It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided essentially for free. It seems you do not understand either vulnerability. I understand it perfectly, did you follow the link I posted to Theo's response to an OpenSSl dev about this very thing or the slides about OpenBSD's mitigation tecniques. It would have been found sooner or later way before it was. Replacing malloc has been described as exploitaion mitigation mitigation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/214362.32904...@smtp130.mail.ir2.yahoo.com
Re: Hardened OpenSSL fork
On 21/04/14 09:21, Kurt Roeckx wrote: OpenBSD also replaced RC4 with ChaCha20, while Linux probably still uses RC4. We should stop using RC4. I figured OpenSSH must be already using arc4random, and sure enough it seems to bundle an implementation of ChaCha already: http://sources.debian.net/src/openssh/1:6.6p1-3/openbsd-compat/arc4random.c?hl=192#L192 There's an strlcpy implementation there too: http://sources.debian.net/src/openssh/1:6.5p1-6/openbsd-compat/strlcpy.c?hl=33#L33 The description of OpenSSL's PRNG[0] sounds similar to what /dev/random on FreeBSD already provides with Yarrow, and the kernel has access to more potential sources of entropy than userland, including hardware entropy generators (instead of OpenSSL engines having to reimplement support for those). [0]: https://www.openssl.org/docs/crypto/rand.html So this might be a good thing on OpenBSD, but it's not a good thing for something that needs to be portable. I'd say the code still looks quite 'portable' in that it is ANSI C and isn't using kernel-specific features. arc4random is just a library routine from their libc and I see no reason it can't be borrowed. OTOH some OpenSSL code tries to be 'portable' - but in really bad ways - trying to implement its own snprintf, bzero, malloc/free, etc., still having workarounds for bugs in ancient/obscure compilers (Visual C++ 5.0, Cray T3E), going out of its way to support big endian x86 and x86_64 systems that don't exist... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53555b57.9090...@pyro.eu.org
Hardened OpenSSL fork
Hi, A few things led me to question whether it is safe for OpenSSL to enable so many features. The heartbeat extension was not likely being used by anyone for its stated legitimate purpose. I've yet to use/need DTLS. I wondered if we could have had something along the lines of an openssl-heavy and openssl-light. But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. From doing that, Ted Unangst found the cause of the bug now known as CVE-2010-5298. And obsolete code such as for SSLv2 or portability with ancient systems is being ripped out. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? The effort curiously has its own fanpage in the style of the vulnerability that triggered it: http://opensslrampage.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53540cf1.5000...@pyro.eu.org
Re: Hardened OpenSSL fork
Heya, On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: I wonder if this might result in an alternate SSL/TLS library we could use in Debian? Probably - but I think there is enough time left for jessie that we don't need to jump to conclusion already and can watch this unfold a bit more and see how OpenSSL upstream reacts etc. Probably it makes sense to discuss this at DebConf and have a decision there. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140420182125.gh10...@raptor.chemicalconnection.dyndns.org
Re: Hardened OpenSSL fork
On Apr 20, Steven Chamberlain ste...@pyro.eu.org wrote: I wonder if this might result in an alternate SSL/TLS library we could use in Debian? Let's see next year how much the OpenBSD thing will be: - portable - interoperable - gaining new features They are removing things like FIPS support which are vital for Red Hat (until they will manage to replace OpenSSL with NSPR everywhere it matters), so I do not expect that it will get a wide adoption in the real world. -- ciao, Marco signature.asc Description: Digital signature
Re: Hardened OpenSSL fork
On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: Hi, But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. One of the problems with anything from OpenBSD is that they only care about OpenBSD, and if you want to use that fork you'll actually have to go and revert some of the things they're doing. Some of the things they're changing are actually good changes, but some are also just wrong. They don't seem to be understanding why things are the way they are and seem to be changing code they don't understand. They also seems to like to do white space changes, which is really helpful. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. This did not allow heartbleed to happen. It might have hidden CVE-2010-5298 more, but it was always there and is unrelated to heartbleed. When using the native malloc you would still have be able to exploit heartbleed, but it will most likely result in different behaviour and might be harder. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? There are alternatives, but I guess you mean alternative to openssl. Currently it actually doesn't look like a good option to me. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140420212629.ga23...@roeckx.be
Re: Hardened OpenSSL fork
previously on this list people contributed: On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: Hi, But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. One of the problems with anything from OpenBSD is that they only care about OpenBSD, and if you want to use that fork you'll actually have to go and revert some of the things they're doing. Not true actually but of course their primary concern is naturally OpenBSD. They takes POSIX seriously and atleast one patch has brought it closer to POSIX standards. It is also clear to me that Theo wants all to follow and benefit from best practice and bug hunting, the fact that there is so much resistance is not his fault... is strlcpy still rejected by glibc on the false premise of not solving truncation despite better performance than strncpy and when it makes finding truncation much easier! when used how they have been applying it to openssl. https://lwn.net/Articles/507319/ Some of the things they're changing are actually good changes, but some are also just wrong. They don't seem to be understanding why things are the way they are and seem to be changing code they don't understand. Based on what? heartbleed happening due to performance for embedded but there is little need and no need for doing so generically. Sure they are ripping much out and rewriting parts just to get it going on OpenBSD initially with the statement on undeadly that portability can be brought back later. OpenSSH development certainly looks more than co-operative to linux portability. They also seems to like to do white space changes, which is really helpful. Apparently it is to them in following the style(9) they are used to. What's the problem, ignoring whitespace for diffing is easy. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. This did not allow heartbleed to happen. It might have hidden CVE-2010-5298 more, but it was always there and is unrelated to heartbleed. It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided essentially for free. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? There are alternatives, but I guess you mean alternative to openssl. Currently it actually doesn't look like a good option to me. If it is more secure then it meets most users needs better and so I disagree. The suggestion was for another package anyway like OpenNTP which avoided the recent security issues. Of course it is too early for this to be done now and who knows how upstream will react but considering their revenue streams that will likely have a lot to do with damage limitation. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/602746.76025...@smtp109.mail.ir2.yahoo.com
Re: Hardened OpenSSL fork
I agree it's not going to be portable in the near term, though there are interesting changes being made and good code review happening. Some dubious entropy sources were (only potentially?) used with RAND_seed/add: digests: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/dsa/dsa_asn1.c.diff?r1=1.7;r2=1.8 private key: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/rsa/rsa_crpt.c.diff?r1=1.2;r2=1.3 There is even a RAND_screen function on Win32 to use a screenshot of the desktop as an entropy source. I had a flashback to the Debian bug, and how uninitialised memory was being used for that purpose. They've ripped out this whole PRNG now to use the one from their own libc: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/rand/rand_lib.c.diff?r1=1.14;r2=1.15 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535476ac.2050...@pyro.eu.org
