Rethinking OpenBSD Security

https://flak.tedunangst.com/post/rethinking-openbsd-security

by zdw • 6 years ago

151 65 6 years ago

flak.tedunangst.com

h2odragon• 6 years ago

Good writeup, fairly made points. It'd be easy to laugh at OpenBSD finding SMTPD vulnerabilities even now (I did); but as TFA points out it's complicated and often hard to see these things.

And that's in OpenBSD which has had the honest effort and passion of scary geeks with no sense of proportion for how many years?

Compare that to the security posture inherent in projects that install with

    sudo bash <(curl -sL someurl.wtf/thatredirectsanyway )

"Secure" computing today is just not going to happen. Not saying its a bad goal, or a waste of time; just that its a metaphysical pursuit of perfection doomed to beautiful failure.

tinus_hn• 6 years ago

Sudo curl is terrible but is it really that much worse than downloading a dvd image and installing it? The main difference is how casually people give away the keys to the kingdom.

jacobush• 6 years ago

To be fair there often is a key chain in place nowadays, for booting a PC. It's a little bit better even though I don't like how basically Microsoft controls the keys.

Hitton2• 6 years ago

It is worse. Notice that h2odragon didn't include "https" on purpose because of how many these install instructions do the same.

irishsultan• 6 years ago

One issue with sudo curl is that it may end up your system in an unusuable (or unknown) state, even if the script you're fetching is not malicious, because your connection can be interrupted and bash will start executing even before the script is fully downloaded.

pjmlp4• 6 years ago

It will happen, slowly but it will, liability law suits and media exposure just need to increase, then more companies will start paying attention to security.

jstimpfle3• 6 years ago

I think some people just need to step up instead of only evangelizing, and actually build something that is useful and "secure"

Oh wait... There are actually tons of such projects. Why did they not take off? (I'm trying hard not to sound cynical because I don't really know that there is absolutely no way that they could, but also I do feel cynical)

ownagefool• 6 years ago

Quite a lot of companies have massive security budgets. The problem is, nobody wants to do the work, so most CISOs just meet vendors and then mostly spend the budget there.

AnIdiotOnTheNet2• 6 years ago

I don't believe that is true. If you look at the history of the world you'll find that security is rarely enough of a priority for anyone for it to receive real attention. I see no reason for computing to change that trend.

sandov• 6 years ago

If anything, liability laws would only make it harder for secure computing to exist and be viable.

odkamkfn• 6 years ago

OpenSMTPD has only been going for 7 years and it's gone through a bunch of changes almost every OpenBSD release.

cat199• 6 years ago

laugh at OpenBSD finding SMTPD vulnerabilities even now

OpenSMTPD is a relative newcomer -

Sendmail: 1983

Exim: 1995

Postfix: 1998

OpenSMTPD: 2008 (2013 as active MTA in OpenBSD)

JdeBP2• 6 years ago

The counterpoint to that is that there is a lot of prior art, and prior mistakes to learn from, for something begun in 2008. So the assumption that it will take the same length of time, and the same learning and development process, to reach parity with other softwares has a flaw.

nine_k• 6 years ago

I suppose you don't do the `curl | bash` thing on your server fleet?

I see how desktops (laptops) are more or less screwed because of the need to run ad-hoc things.

But servers, which are much more controlled ad limited environments, could be more secure. A lot of orgs follow rather sane software security policies; if the software itself were less vulnerable, it would help.

For a lot of end users that would make a significant difference, because they run most of their critical software in the browser anyway.

ainar-g2• 6 years ago

Honest question. Why not just completely outlaw code like:

  exec("/bin/sh", "-c", "...");

And its friends? It feels like it does way more harm than it does good.

peterwwillis• 6 years ago

Because arbitrary "Thou Shalts" do not prevent security holes. Make a restriction, and hackers will find the cracks around it. The only way to stop them is to fill the cracks, and the only way to find the cracks is to look for them. Now, certainly if there was an exec() replacement that was more secure, you should use that; but banning exec() entirely is doing more harm to functionality than good to security.

Particularly, the exec() bug here is one of misunderstanding the security guarantees of interfaces; particularly, that there are none. Not validating inputs is the single most universally known security practice, and yet it wasn't done here. On top of that, not using typed objects further increases potential for attacks. This was just shit security design. exec() had about as much to do with the bug as your brakes have to do with you locking up your wheels when traveling too fast in rain/snow/ice. (that you should have been going slower, not that the brakes are defective)

ainar-g2• 6 years ago

I haven't proposed to ban exec entirely. I've proposed to ban exec uses that just sends data into a shell.

hedora• 6 years ago

Sometimes you need to tell something to programmatically spawn a shell:

watch bash -c “ps | grep argname”

and similar.

JdeBP2• 6 years ago

Because it wasn't what actually did the harm in this case. That was a lack of some kind of "--" delimiter, and not using the Bernstein checkpassword approach.

And because there are genuine uses for it. I use it in service ./run programs, for example, where simple tooling is not enough and I want shell script things like variable expansions and conditional operators.

The first reason is of particular note because it is two good practices to get used to: employing "--" as the norm; and not passing user credentials around in either environment variables or command-line arguments. (Bernstein checkpassword receives the user credentials as NUL-terminated strings over a pipe.)

* https://cr.yp.to/checkpwd/interface.html

smitty1e2• 6 years ago

Privilege separation is a key component of OpenBSD security, and interprocess communication is at the heart of it. More focus on what can go wrong with corrupted processes would help. Secure browsers are evolving longer and longer kill chains. smtpd in particular is supposed to be secure against memory corruption in the network processes, but the ease with which it can control the parent is pretty alarming.

This invites the sincere, honest technical inquiry as to why OpenBSD doesn't have an SELinux-style Mandatory Access Control (MAC) facility, but is OK with the traditional Discretionary Access Control (DAC).

GeorgeWBasic• 6 years ago

They have pledge(2) and unveil(2) instead.

smitty1e2• 6 years ago

Excellent. Thank you.

st3fan4• 6 years ago

AFAIK (correct me if I am wrong) OpenBSD does not have a single unit test.

No unit tests.

There is so much code that parses text input and yet I can’t find a single test that actually shows that the code works and that it properly deals with malicious input.

How do OpenBSD developers test? How do they make sure changes do not regress things.

Why is unit testing just not a thing? (Same for many other C based projects)

clarry4• 6 years ago

Which one of these bugs would have been prevented by unit tests? Probably none, because you'd have to know about the bug in order to craft a test that exploits it.

sildur• 6 years ago

Unit tests could prevent reintroducing old bugs.

st3fan4• 6 years ago

Sometimes that is definitely true.

But very often when you spend time to write unit tests you discover limitations and bugs in your code while you come up with test scenarios.

The only thing that the FTP bug needed was a "test_redirect_responses()" test. The SMTPd bug was all about parsing user input. Ideal candidate for unit testing and probably even some fuzzing.

brohee• 6 years ago

You're wrong. They are in their own directory in the source tree (https://cvsweb.openbsd.org/src/regress/).

ld.so for example is pretty well exercised (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/libexe...)

st3fan4• 6 years ago

Can you point me to a unit test that validates for example parsing of incoming commands to opensmtpd or ftpd or ntpd?

Nothing. It is just not a common practice it seems.

Now I don't think unit tests are a silver bullet. But having just code and zero tests is definitely a huge red flag for me.

api• 6 years ago

There's a factor with OpenBSD that isn't mentioned here at all: it has very few developers.

A single developer can hold much or all of the state and important security considerations in their head. A small team can communicate well and can hold to a single style, and members of a small team can ask each other things easily. Single developers or small teams can write secure code in unsafe languages.

The problem is that this doesn't scale. Add a large number of developers and it becomes increasingly difficult to police security in an unsafe language. Safe languages, unit tests, and fuzzing help a lot more here by making large classes of errors difficult or impossible to manifest or catching them automatically.

Linux is a bit special here: it has a lot of developers but a small number who are responsible for approving things, and it's so massively important and popular that it has a lot of eyeballs on it and gets a lot of automated testing. Security issues still creep in though.

pjmlp4• 6 years ago

Creep it enough, that Google created the Kernel Self Protection Project.

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

One of their first activities was to clean the kernel from all usage of C's VLA.

chasil• 6 years ago

You might claim that the security design of OpenBSD does not scale, and the observations of the parent article do cast some reasonable doubt on code security.

However, a number of projects from OpenBSD have been widely adopted and are successful in their own right, for example:

    C:\>ssh -V
    OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

The two projects above, OpenSSH and LibreSSL, have been even more strongly adopted by Apple, as I understand it. OpenSSH is adopted by just about everybody.

Google Android's "bionic" C library is also based on OpenBSD, and I would imagine that the coding concerns for libc will trickle down.

OpenBSD is not the sum of its parts, as so much of it is used in other environments.

loeg3• 6 years ago

Bionic took pieces from OpenBSD, as well as other places[1].

[1] https://en.wikipedia.org/wiki/Bionic_(software)#Components

jancsika• 6 years ago

Hi Ted,

Please change your page design so that the content is centered horizontally. Otherwise we have to swivel ourselves toward the left side of the screen to read the article.

Sincerely, My Eyes

patrec• 6 years ago

OpenBSD aims to be a secure operating system

Pretty idiotic aim if you're writing it in C.

Rethinking OpenBSD Security

Related Stories