10.22.07
OpenBSD, the “Secure” OS
Was playing around with OpenBSD a little bit to test configuring and building of GNU Wget on non-GNU Unixy systems. In particular, I was interested in ensuring that things work properly when various GNU library components (notably, the gettext internationalization package) are not available. OpenBSD was chosen because it’s relatively small, and places a strong emphasis on correctness.
My first attempt involved compiling GNU m4, automake and autoconf by hand. This did not work out too well, and resulted in generating some bizarrely broken configure scripts for Wget. When I instead used the official packages for OpenBSD for automake and autoconf, everything went much more smoothly, and Wget configured and installed fine without NLS (native language support). I’ll go back when I have time to try to understand what went wrong with the manual builds of those GNU tools, as there are some systems where you can’t obtain “official” binaries for them, and I want to be able to help people address problems with configuring Wget that are really problems with their autoconf/automake setup.
OpenBSD is famous for being the “secure by default” operating system, priding themselves in having had only two remotely exploitable security vulnerabilities throughout their entire history. I am not convinced that this reputation is earned, however. Judging by what Core Security had to go through to get OpenBSD to acknowledge a security vulnerability, it appears OpenBSD manages to claim so few security vulnerabilities, mainly by using their own definition for what a “security vulnerability” is. For instance, they will not acknowledge a remote denial-of-service attack as a security vulnerability, reserving the term for exploits that can execute arbitrary code. While the latter is certainly a greater concern, I’m not sure how you can view bringing a system to a grinding, screeching halt, potentially costing big money while your mission-critical system gets brought back up, and a defense erected against the DoS to prevent it from recurring, as “not a security vulnerability.”
Now that I’ve had a chance to play with it, I was dismayed to discover that non-root users get a dot [.] appended to their PATH environment variable (which tells the command shell where to look for programs whose names you type in). This has long been considered to be a security vulnerability in the Unix world, as a sneaky user who places malicious scripts in his home or in /tmp, whose names are mistyped versions of common commands, could trick other users, including those with administrative access, into giving them greater access to the system. Apparently the OpenBSD developers’ reasoning is that it’s not as bad as prepending the dot (which wouldn’t even require lurking for typos: you could put the properly-spelled scripts in various locations), and that it’s better than letting inexperienced users prepend the dot (a decent refutation of this, of course, is providing a simple comment showing people the correct way to set the PATH). Update 2008-02-10: Reasoning for why dot is in the PATH. Part of a longish thread.
I found it annoying that anytime you link a program that uses the C strcpy() or strcat() library functions, it warns you that those are “almost always abused”, and you should use (non-portable) strlcpy()/strlcat() instead. IME, while misuse of strcpy() and the like are certainly common, “almost always” is a gross exaggeration, and there are many instances (mainly, when you know exactly what the lengths of the source string and destination buffer are) when it is a better choice than strlcpy()point of Free Software is the freedom to modify software to suit your needs.
Of course, the OpenBSD developers have also given us OpenSSL (internet encryption library), and OpenSSH (secure remote shell access), which are [is] probably among the very most useful and pervasive pieces of software for Unixen, for which I am very grateful (Wget uses OpenSSL to handle encrypted web downloads and the like).
Nat said,
10.26.07 at 11:26 am
Micah you are operating without sufficient information, using logical leaps and hearsay for the basis of many conclusions. There is no replacement for actual directly retrieved data, you must obtain some in order to correct your post’s further proliferation of misconceptions commonly held.
The largest of your errors is OpenSSL, which is developed by OpenSSL, not OpenBSD. OpenBSD makes OpenSSH, and OpenSSH uses OpenSSL (as does OpenBSD), but the two development teams are unrelated to each other. OpenBSD developers have sent code upstream to OpenSSL developers, but there is no OpenSSL developer which is also an OpenBSD developer. OpenSSL is based on SSLeay, an older SSL implementation and has a licence that is markedly more restrictive than that which is used by the OpenBSD developers, in fact, that restrictive licence is why OpenSSL isn’t used with GNU programmes, because it has restrictions which the GPL does not.
OpenSSH isn’t just prominent on Unix systems, it’s inside many non-unix command line operating systems, including the Cisco IOS.
Another misconception is the OpenBSD string function set, not only are they portable, any operating system with OpenSSH on them has the set. The only C libaries which don’t have the OpenBSD-originated functions are the glibc’s and the Windows c libraries, other operating systems have them, but the maintainers of the GNU library have a strong dislike of OpenBSD. So no, they are portable functions, they’re even under BSD terms, it’s just that Ulrich Drepper is a twat that thinks everyone should use memcpy instead.
Security has nothing to do with what happens after a system has been compromised, period, security is in preventing the problem in the first place. If someone has already gotten into your system and planted a binary on it, then they can easily add to your $PATH. Security is containment and prevention, not random stupidity.
Your third hand discussion of the vulnerability by Core Security is silly to say the least, if every single bug ever was declared a security vulnerability, it would take away all meaning of the term, and if every time a bug was found, developers spent the month that Core Security’s people spent finding the exploit instead of just fixing it, nothing would ever improve in the system. A bug was found, it was fixed, Core Security insisted it was more important than a reliability issue, OpenBSD developers said they didn’t see the exploitability and moved on, Core Security then spent a huge amount of time finding an exploit for it, during which time a fair bit of change happened in OpenBSD, if OpenBSD used it’s resources like Core Security did, the system would run in the same fashion as OpenBSD 2.6 did. And indeed, a denial of service is no vulnerability, anything can be DOSed, period, there is no avoidance of it, a DOS does not break a system, it takes it down, the data on that system remains in tact and thus there is an inconvenience, but not a breach. Mitigation of a DOS does not prevent DOSes, nothing can, if someone wants to DOS, it is very easy to do.
If you read through the ports patchsets you’ll find a significant amount of work is required to make such Linux-centric software work on other operating systems, it is better to use the ports system than to try and roll your own in almost all cases.
Micah said,
10.26.07 at 11:49 am
Another misconception is the OpenBSD string function set, not only are they portable, any operating system with OpenSSH on them has the set.
That’s a silly statement. Obviously, GNU systems have OpenSSH, while lacking those string functions, at least as far as the system library is concerned. In any case, what I mean by portable in this context, is standardized. strlcpy() and friends are not in any standard of which I’m aware, whereas strcpy() is in C and POSIX. And, as I already pointed out, there are contexts in which strcpy() is clearly a better choice over strlcpy(), in which case the link warnings are nothing but noise.
Security has nothing to do with what happens after a system has been compromised, period, security is in preventing the problem in the first place. If someone has already gotten into your system and planted a binary on it, then they can easily add to your $PATH. Security is containment and prevention, not random stupidity.
This statement is broken in so many ways it’s hard to know where to start. In the first place, you seem to be implicitly saying that all users on an OpenBSD have to be trusted users, which is a pretty silly thing to expect. In the second place, just because someone manages to get access to an unprivileged account, doesn’t mean you should make it easier for per to get access to a privileged one. And the “then they can easily add to your $PATH” is a complete non-sequitur, to say the least. We are, after all, talking about binaries in public locations, such as /tmp.
if every single bug ever was declared a security vulnerability
That is not relevant to the point. Nobody is talking about every single bug, we’re talking about DoS vulnerabilites. Everyone else in the world, except the OpenBSD folks, consider susceptability to DoS to be a security issue. OpenBSD does not get to redefine the term for themselves, in order to decrease the number of such vulnerabilities.
Security is not the difference between a “breach” and “system going down”. Security is security. I do not consider any machine that will die upon receiving a crafted packet to be “secure”, and neither does most of the rest of the world. It is indeed good that the user can’t trash the data; that doesn’t make it suddenly not an issue of security at all.
anything can be DOSed, period, there is no avoidance of it
Gosh, I guess we’d better tremble then: them terr’rists can simply bring down the entire interweb on a whim!
…But hey, I knew what I was getting myself into when I attacked people’s precious belief in OpenBSD as an ultra-secure operating system. And I’m not saying it’s not pretty secure: it clearly is. It’s just not as secure as it presents itself as being, and a certain amount of deception is involved in the claim.
Nat said,
10.26.07 at 12:00 pm
If you have a user you don’t trust, you chroot them, or you don’t have that user, there can be no other choice. If the user isn’t trusted, why the /fuck/ are they a user?
When a bank locks down to prevent a robbery, is that now somehow not a security measure? The goal is to maintain the funds contained therein, is it not? To maintain the security of the capital and materials which the bank holds? A lock down prevents access to those resources, but it maintains there security. A denial of service is that failed robbery. The security of the data is maintained at the minor inconvenience of not gaining immediate access to it, that is security.
You’re a fool Micah, and I assumed you were smarter than that, I am sorry for the inconvenience, next time I’ll just ignore you.
Micah said,
10.26.07 at 12:20 pm
If you have a user you don’t trust, you chroot them, or you don’t have that user, there can be no other choice. If the user isn’t trusted, why the /fuck/ are they a user?
Right… guess you’ve forgotten why Unix supports multiple users in the first place, then. Sheesh. Just because you sell someone an account on your machine, doesn’t mean that you just assume they’re trustworthy.
Why bother with users at all? Why not just give everyone root access?
You’re a fool Micah, and I assumed you were smarter than that.
Right. That statement somehow makes you look so much smarter than me. What are you, fifteen?
Micah said,
10.26.07 at 12:33 pm
(Please note, I reserve the right to summarily delete anonymous trolls. I’ve left the previous messages up because I find them funny as hell; but further comments really need to provide an (unpublicized) email address that is not asdf@asdf.ca, at least if they’re going to be insulting.)
Update: naturally, ignoring my warning here, and per own previous statement that phe would now just ignore me, Nat posted yet another comment. I’ve removed it, as promised. Nat, if you’d like to have a voice, stop posting anonymously. I’d respond privately, but since you haven’t given me a real address…
If you want to have meaningful conversations on the Net, you need to learn to keep a reign on your emotions. Slewing insults does not a sound argument make, and if your arguments are in fact solid, you only damage them by acting like a child. You do not impress anyone by threatening to ignore them in the future: if you find that someone is worth ignoring, the very best course of action is to just start ignoring them.
Yuhong Bao said,
07.27.09 at 3:19 pm
“I found it annoying that anytime you link a program that uses the C strcpy() or strcat() library functions, it warns you that those are “almost always abused”, and you should use (non-portable) strlcpy()/strlcat() instead.”
Well, MS VC 2005 and later do the same thing, only that they use strcpy_s()/strcat_s() instead, and yes it is also non-portable and non-standard.
Kevin Chadwick said,
01.05.10 at 2:42 pm
I’d have to say I’m mainly on Nat’s side.
Theo says you should use full paths and shouldn’t run commands from the current directory.
noexec /tmp
nat said if you want untrusted users then chroot them. Do you trust random website users.
Most people will block ipv6 as it is still becoming stable and not widely used. I know I did. You can make ipv4 as secure, in fact more secure with a bit of work anyway, though you may run out of addresses.
There is a lot of truth to everyone being vulnerable to DDOS especially with the likes of conficker around. Whitehouse, microsoft (were lucky) and A small attack from russia making authorities consider cutting off parts of the internet spring to mind.
They also state 2 remote holes, is a dos a remote hole.
Security is a process not a product. (Bruce Schneier)