OpenBSD Project Disgusted, Forks OpenSSL

[PC LOAD LETTER]

http://undeadly.org/cgi?action=article&sid=20140415093252


The denizens of lobste.rs (and no doubt you, eagle-eyed reader!) have made note of the ongoing rototilling of the OpenSSL code in OpenBSD, and Joshua Stein ([email protected]) has chimed in (https://lobste.rs/s/3utipo/openbsd_has_started_a_massive_strip-down_and_cleanup_of_openssl/comments/fkwgqw) with a quick breakdown of the action thus far:
Changes so far to OpenSSL 1.0.1g since the 11th include:


Splitting up libcrypto and libssl build directories
Fixing a use-after-free bug
Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
Removal of most (all?) backend engines, some of which didn’t even have appropriate licensing
Ripping out some windows-specific cruft
Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
KNF of most C files
Removal of weak entropy additions
Removal of all heartbeat functionality which resulted in Heartbleed

To clarify, not all of the cryptographic engines were removed; the padlock and aesni engines are still in place.
As always, it's heartening to see a concentrated effort on such a critical software component.

[PC LOAD LETTER]

For those that don't know, OpenSSL Project is a separate entity from the OpenBSD project. OpenBSD is an operating system (BSD variation) with a focus on security. When the heartbleed bug became public, Theo de Raadt (creator of OpenBSD) railed on the maintainers of OpenSSL for being a bunch of fucking dumbasses. They (OpenBSD) decided, "Fuck this, we're forking OpenSSL and cleaning it up." Forking an open-source project means to take the source code and release it under a separate project.

Apologies for the double-post, for some reason when I try to edit my original post it's just ... blank.

[tallguy]

For security and anonymity online I recommend taking a look at this:

https://tails.boum.org/

Tails is an operating system optimized for anonymity and it's used by the likes of Edward Snowden and Glenn Greenwald to keep their digital lives as secure as possible. In its developers' words:


Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship almost anywhere you go and on any computer but leaving no trace unless you ask it to explicitly. It is a complete operating system designed to be used from a DVD, USB stick, or SD card independently of the computer's original operating system.

[PC LOAD LETTER]

For security and anonymity online I recommend taking a look at this:

https://tails.boum.org/

Tails is an operating system optimized for anonymity and it's used by the likes of Edward Snowden and Glenn Greenwald to keep their digital lives as secure as possible. In its developers' words:
Tor wouldn't have necessarily protected you from this whole thing. It's mostly bad for hidden service and relay ops, though.

https://blog.torproject.org/blog/openssl-bug-cve-2014-0160




Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug (https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F), this shouldn't allow an attacker to identify the location of the hidden service [edit: if it's your entry guard that extracted your key, they know where they got it from]. Also, an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.

[Sea]

Theo de Raadt is such a bleeding-heart (heh). OpenBSD security is ridiculously poor. If you're not using it, don't start. If you're using it, stop.

[PC LOAD LETTER]

Theo de Raadt is such a bleeding-heart (heh). OpenBSD security is ridiculously poor. If you're not using it, don't start. If you're using it, stop.
Care to explain why? I'd stop using it if I had a good enough reason to.

[Sea]

Care to explain why? I'd stop using it if I had a good enough reason to.http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/

I was just gonna edit that post and add this link.

The security features just aren't there. You don't just use the base system -- you no longer use OpenBSD, you use GNU/OpenBSD. Even if the OpenBSD base system were perfectly secure, all other holes are open. The 3rd party packages in the OpenBSD project are horribly outdated, with all the security holes inherent to using obsolete software.

If you want better security, set up a linux box and do all the basic configuration. Install QEMU and make sure your kernel has KVM support. Do all your work in VMs. Your host needn't even face the internet. This way, you can set a solid layered model with a dedicated DMZ / honeypot and firewall. Set up and configure fail2ban on your VMs. If you suffer a breach, you can pull a VM offline and fix it.

[PC LOAD LETTER]

http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/

I was just gonna edit that post and add this link.

The security features just aren't there. You don't just use the base system -- you no longer use OpenBSD, you use GNU/OpenBSD. Even if the OpenBSD base system were perfectly secure, all other holes are open. The 3rd party packages in the OpenBSD project are horribly outdated, with all the security holes inherent to using obsolete software.
I don't use it as a desktop system ... Most people don't. I use it to play around with network appliances. Not bleeding edge doesn't mean insecure, it's usually the other way around ... that's why server-oriented OSes, like OpenBSD, don't have the brand new variations of packages. And if you insist on having the latest version, there's nothing stopping you from compiling it and installing it. If a user can't do that, they probably shouldn't be near BSD. Also, If you're running OpenBSD, you better know how to apply backported security patches (http://www.openbsd.org/errata54.html).

And on the off chance I do have a port installed, it's not usually affiliated with GNU. Most of their shit is a reimplementation of classic Unix tools. Which BSD also did. There's no reason for me to install GNU's userland tools on a BSD system. The only thing I can think of off-hand is GCC, and OpenBSD ships with LLVM/CLANG, so that's optional. Where's the GNU/OpenBSD come from?

Also the article is out of date as it talks about sendmail, which was abandoned after they developed OpenSMTPd in-house. BIND used to be swiss cheese but that was 15 years ago. None of that is relevant.

The article is some guy whining about MAC and third party software for several paragraphs. MAC aren't necessary if the system is configured correctly (chroot, etc) and the source code has been audited. Yeah, yeah, third party software, openbsd isn't a very good desktop OS, so that's not even its intended market. And they can't secure every piece of third-party software, the burden is on the user to make sure the software is trustworthy if it's not in the control of the OpenBSD project. If you're using OpenBSD, it's been made clear that the ports collection is not supported by the OpenBSD project. You actually have to go out of your way to enable access to it. And it's stated several times that it's not supported and potentially contains vulnerabilities.

[edit]

This was put in after I hit reply so I didn't see it in Sea's original post


If you want better security, set up a linux box and do all the basic configuration. Install QEMU and make sure your kernel has KVM support. Do all your work in VMs. Your host needn't even face the internet. This way, you can set a solid layered model with a dedicated DMZ / honeypot and firewall. Set up and configure fail2ban on your VMs. If you suffer a breach, you can pull a VM offline and fix it.

You can use OpenBSD as a guest os. And as far as fail2ban goes, if security is a top priority, why are you not using key-based authentication instead of passwords for, eg, SSH/SFTP? If you were, you wouldn't be suggesting fail2ban. And in an ostensibly secure system, why are you advocating the use of a daemon which requires root privileges to run (fail2ban) and faces the public internet? That's a huge vulnerability and a red flag to me. Also, MAC (the main focus of the article you posted) aren't enabled by default in the vast majority of linux distros, the 'basic config' as you mention. it's something you have to configure by hand. And SELinux, etc, isn't exactly a magic fix ..... see here for details (http://www.exploit-db.com/exploits/9191/).



Abusing this arbitrary code execution to:
* Disable auditing
* Disable SELinux
* Disable AppArmor
* Disable LSM
* Make userspace believe SELinux remains in enforcing mode
* Give ourselves full privileges and capabilities
* Appropriately increment refcnts so as to be
* 100% reliable and repeatableYep, MAC are a magic fix. Totally worked for Vista, too.

[Sea]

For those that don't know, OpenSSL Project is a separate entity from the OpenBSD project. OpenBSD is an operating system (BSD variation) with a focus on security. When the heartbleed bug became public, Theo de Raadt (creator of OpenBSD) railed on the maintainers of OpenSSL for being a bunch of fucking dumbasses. Yes, he as a history of such behavior:
http://beta.slashdot.org/story/05/06/17/127206/linux-for-losers-according-to-de-raadt
http://article.gmane.org/gmane.os.openbsd.misc/134850

I don't use it as a desktop system ... Most people don't.Theo uses it as a desktop system. :glare:
I use it to play around with network appliances. Not bleeding edge doesn't mean insecure, it's usually the other way around ... that's why server-oriented OSes, like OpenBSD, don't have the brand new variations of packages. And if you insist on having the latest version, there's nothing stopping you from compiling it and installing it. If a user can't do that, they probably shouldn't be near BSD. Also, If you're running OpenBSD, you better know how to apply backported security patches (http://www.openbsd.org/errata54.html).Right, and that's why we don't use bleeding edge software. "Horribly outdated" and "thoroughly tested" are two different things, mind you.
And on the off chance I do have a port installed, it's not usually affiliated with GNU. Most of their shit is a reimplementation of classic Unix tools. Which BSD also did. There's no reason for me to install GNU's userland tools on a BSD system. The only thing I can think of off-hand is GCC, and OpenBSD ships with LLVM/CLANG, so that's optional. Where's the GNU/OpenBSD come from?I assumed that you were using it as a desktop system, which would imply that you have the OpenBSD with a bunch of crusty outdated GNU-licensed software from their repos.
Also the article is out of date as it talks about sendmail, which was abandoned after they developed OpenSMTPd in-house. BIND used to be swiss cheese but that was 15 years ago. None of that is relevant.There are other valid points in that article (see below).
And as far as fail2ban goes, if security is a top priority, why are you not using key-based authentication instead of passwords for, eg, SSH/SFTP?Learn how F2B works and what it is before you talk out of your bumbum. I do use key-based authentication; you seem to have it in your head that F2B is only about SSH & friends. That's false, you're probably thinking of DenyHosts which is a different piece of software altogether. Have a look at the default config to see everything F2B can do:
https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf
And in an ostensibly secure system, why are you advocating the use of a daemon which requires root privileges to run (fail2ban) and faces the public internet? That's a huge vulnerability and a red flag to me.It doesn't face the internet. It looks for suspicious activity in standard system logfiles and carries out a user-configurable action in response. That's how an IPS works.
Also, MAC (the main focus of the article you posted) aren't enabled by default in the vast majority of linux distros, the 'basic config' as you mention. it's something you have to configure by hand. And SELinux, etc, isn't exactly a magic fix ..... see here for details (http://www.exploit-db.com/exploits/9191/).

Yep, MAC are a magic fix. Totally worked for Vista, too.Talk about outdated! Kernel 2.6.30 is nearly 5 years old! I never sold MAC off as a magic fix, nor did the author of that article, and to say that's a flaw in MAC is just silly. It's a flaw in the implementation (SELinux). Does a flaw in Microsoft's BitLocker mean we all should stop using AES? Does heartbleed mean we shouldn't be using SSL any more? Does the horrible weakness of lanman hashes mean we shouldn't be putting passwords and passphrases on our computers anymore? No, that would be dumb. SELinux isn't supposed to be a magic fix. Security comes on layers, for the same reason that you can't put a coat of magic titanium paint on your house to keep the burglars away. If you're going to discount a widely-used and widely-respected security too because you "don't need it anyway", perhaps security isn't the field for you.

[PC LOAD LETTER]

Yes, he as a history of such behavior:
http://beta.slashdot.org/story/05/06/17/127206/linux-for-losers-according-to-de-raadt
http://article.gmane.org/gmane.os.openbsd.misc/134850
Theo uses it as a desktop system. :glare:Right, and that's why we don't use bleeding edge software. "Horribly outdated" and "thoroughly tested" are two different things, mind you.
No Shit!

Learn how F2B works and what it is before you talk out of your bumbum. I do use key-based authentication; you seem to have it in your head that F2B is only about SSH & friends. That's false, you're probably thinking of DenyHosts which is a different piece of software altogether. Have a look at the default config to see everything F2B can do:
https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf
It doesn't face the internet. It looks for suspicious activity in standard system logfiles and carries out a user-configurable action in response. That's how an IPS works.I know what fail2ban is. It is a non-isolated daemon running with root privileges. If you don't understand what's bad about this, GTFO and go back to ubuntuforums.


Talk about outdated! Kernel 2.6.30 is nearly 5 years old! I never sold MAC off as a magic fix, nor did the author of that article, and to say that's a flaw in MAC is just silly. It's a flaw in the implementation (SELinux).OK, so you have no idea what that vuln was. It was a null pointer reference in the kernel. SELinux couldn't stop it, and it allowed you to shut down SELinux (via arbitrary code x) to do other fun things with your target. None of that was related to an implementation flaw, because that's not where the vulnerability laid. It was just a failure of MAC to do what it was billed for. The author of that article spent most of that space whining about how OpenBSD doesn't have MAC. And then a little bit of whining about memory-safer c functions like strlcpy. Dumbass even calls it a library call, and doesn't even expand on his argument regarding strlcpy. The author is another idiot writing an irrelevant blog.


Does a flaw in Microsoft's BitLocker mean we all should stop using AES? Does heartbleed mean we shouldn't be using SSL any more? Does the horrible weakness of lanman hashes mean we shouldn't be putting passwords and passphrases on our computers anymore? No, that would be dumb. SELinux isn't supposed to be a magic fix. Security comes on layers, for the same reason that you can't put a coat of magic titanium paint on your house to keep the burglars away.This would be relevant if I were arguing that a vuln in the Linux kernel means we should scrap Linux. At this point you just look like a rabid idiot.


If you're going to discount a widely-used and widely-respected security too because you "don't need it anyway", perhaps security isn't the field for you.It's not necessary because it DOESN'T WORK. chrooted environments actually work. Putting MAC ahead of proper, safe coding techniques and other basic security precautions that the OpenBSD team focuses on is like saying "It's OK if I get shot by some random asshole, I carry gauze! I'll be fine!" instead of doing whatever you can to pre-emptively reduce the possibility of being successfully attacked in the first place.

[Sea]

No Shit!Since you responded to my complaint about OpenBSD's extras being horribly outdated with an unrelated remark about why bleeding-edge is bad (we know this already, that's why it's called bleeding-edge), which demonstrates that you are confused about the difference between these things, I have no choice to assume that by "no shit" you mean that you just had a eureka moment.
I know what fail2ban is. It is a non-isolated daemon running with root privileges. If you don't understand what's bad about this, GTFO and go back to ubuntuforums.Upon my mentioning fail2ban you immediately made the false claim it actively listens over some or another port (what else do you mean by "facing" the public internet? of course your DMZ faces the public internet, that's why it's the DMZ..) and you brought up why password-based auth is not ideal with SSH, which (unless you just googled "what is fail2ban" and saw some article about ssh) is both obvious and irrelevant, since helping out with SSH security is only part of what fail2ban does. So you don't know what fail2ban is.
OK, so you have no idea what that vuln was. It was a null pointer reference in the kernel.Coolio Julio, I just assumed it was "look, we can use selinux to break into your box!!1". My bad.


OK, so you have no idea what that vuln was. It was a null pointer reference in the kernel. SELinux couldn't stop it, and it allowed you to shut down SELinux (via arbitrary code x) to do other fun things with your target. None of that was related to an implementation flaw, because that's not where the vulnerability laid. It was just a failure of MAC to do what it was billed for.And it's been fixed now, hasn't it?
The author of that article spent most of that space whining about how OpenBSD doesn't have MAC.S/he also points out things like the following:

It should also be noted that the OpenBSD team uses a different definition of security vulnerability, limited to vulnerabilities that are allow for remote arbitrary code to execute. While most people may consider a DOS attack or local privilege escalation problems to be vulnerabilities, the OpenBSD team disagrees. If we use a more generally accepted definition of security vulnerability, OpenBSD suddenly has a far greater number than two remote holes in the default install a heck of a long time.This is quite worrying on its own, especially when considering that
The OpenBSD team seems very reluctant to actually admit security problems and work towards fixing them. One such example is this CoreSecurity advisory (http://www.coresecurity.com/content/open-bsd-advisorie) from 2007. Instead of working and testing to see the extent of the damage that could be caused by a particular vulnerability, they prefer to dismiss and assume arbitrary code execution is impossible until pushed by Core releasing proof of concept code to show otherwise. This is similar to behavior observed by many corporations. Unfortunately this seems to be typical behavior rather than an exception going by the various mailing list threads when a vulnerability is reported.For homework, you can find some example of oBSD security holes and the procedure for fixing them that followed. Compare it to the procedures followed with, for example, RHEL.
And then a little bit of whining about memory-safer c functions like strlcpy. Dumbass even calls it a library call, and doesn't even expand on his argument regarding strlcpy. The author is another idiot writing an irrelevant blog.Just because the author is less knowledgeable than you about certain things does not make them a dumbass. That's just ad hominem. The author may not be a coder, but when it comes to the security features of various operating systems, for instance, the author's expertise is quite evident.
This would be relevant if I were arguing that a vuln in the Linux kernel means we should scrap Linux. At this point you just look like a rabid idiot.Well, you used it as anecdotal evidence to support your claim that lunix isn't to be preferred over oBSD. So yeah, at this point you just look like an evangelist.

It's not necessary because it DOESN'T WORK. chrooted environments actually work. Putting MAC ahead of proper, safe coding techniques and other basic security precautions that the OpenBSD team focuses on is like saying "It's OK if I get shot by some random asshole, I carry gauze! I'll be fine!" instead of doing whatever you can to pre-emptively reduce the possibility of being successfully attacked in the first place.The "ehnahced chroot" functionality of oBSD is not specific to oBSD:
http://en.wikipedia.org/wiki/Operating_system-level_virtualization#Implementations

And.. SELinux doesn't work? You should be contacting SANS and sending flowers to the Torvalds family, not arguing on RevLeft!

edit: If you want me to reply, pick 3 or 4 items. Otherwise I won't bother since this is just a waste of time anyway.

[PC LOAD LETTER]

edit: If you want me to reply, pick 3 or 4 items. Otherwise I won't bother since this is just a waste of time anyway.
Glad we can agree on something. I find it entertaining to be categorized as an OpenBSD evangelist, yet I use Linux 90+% of the time and also use FreeBSD more than OpenBSD. I have a desktop setup with FreeBSD. They all have their uses in various situations.