Hacker News Reader

Comment by executesorder66 | Hacker News Reader

I'm curious why the author says Linux is "insecure, anti-secure, and anti-privacy software" Can anyone explain this?

Also, why OpenBSD specifically, and not FreeBSD for example?

I'm lumping Linux in that group because my impression is that Linus is ambivalent about security--it seems to be just another feature to him (see http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...). Additionally, with most of the popular distros, once I install the OS, I have to spend a bunch of time locking things down before I do anything else, whereas OpenBSD has pretty good defaults that I can build up from. Also, when Ubuntu, one of the most popular Linux distros, started capturing searches by default, that got me questioning their commitment to privacy.

That's not to say there aren't distros and contributors to Linux that care deeply about security--clearly there are. I just don't find the overall ecosystem nor the most popular distros nearly as focused on or as trustworthy on security and privacy. And as the stakes get higher with more of our lives going digital and more companies, states, and criminals trying to take advantage of that trend, I worry.

As for OpenBSD vs FreeBSD, I've had an easier time getting OpenBSD working on my hardware and OpenBSD seems to me more concerned with, focused on, and practically innovative on security--that is to say, they don't just introduce new security features that can be configured and used by someone smarter than me, the OpenBSD folks work hard to introduce new security tech that's on by default with no special knowledge required by the end user, i.e. pledge, W^X.

Then modify the claim to say "some Linux kernels/distros" instead of Linux as a whole. Meanwhile, thanks to CompSci, there's Linux's (eg Criswell's SVA-OS) and FreeBSD's (eg CheriBSD on CHERI) that run with way more security than OpenBSD. They push the state of the art. So, it's a mixed bag.

OpenBSD is actually no different. The developers care a lot about security and quality. Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. It's just the kernel and select userland that gets their attention to quality due to limited staff (and their preferences).

> Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp.

Are these "shoddy applications" not more secure on OpenBSD due to the various mitigations applied to userland software?

We don't know. OpenBSD has so little market share that virtually nobody is testing those mitigations. However, many are similar to mitigations developed on other platforms and beaten. So, they'd probably be beaten with effort, too.

Don't you love reasoning by precedent? Makes these judgment calls so much easier. :)

People are testing the mitigations. For example Qualsys' audit of OpenSMTPD[0] noted that a buffer overflow they found was not exploitable on OpenBSD as even a single byte overflow would smash the stack canary.

[0] https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt

That's not trying to break the mitigations: it's simply testing if they stop an exploit which isn't designed to bypass the mitigations. Really easy to pull off. :) Below are examples of a clever scheme for stopping control flow attacks and a successful attempt to breaking it. When I say testing the mitigations, I mean work like what's in the second paper.

https://www.usenix.org/system/files/conference/usenixsecurit...

http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf

Note: Native Client, which protects Chrome, is a form of Control-flow Integrity. Hence, me using it as an example.

I'm not seeing your point. A vulnerability was found in OpenSMTPD. That vulnerability could not be exploited on OpenBSD because there was no way to overflow the buffer without smashing the stack canary. If you had the same version of OpenSMTPD running on a generic Linux kernel or on Mac OS X, it was vulnerable. On OpenBSD it was not. Ergo, OpenSMTPD running on OpenBSD is more secure than OpenSMTPD running on other platforms that do not provide the same mitigations.

At least, that's the way I see it.

Now, are you saying that because it's possible to bypass the mitigations in some other cases, preventing that vulnerability (and others) doesn't matter?

Or, are you saying that it would be possible to craft an exploit that bypassed the stack protection for that particular vulnerability? In which case I would love to see your PoC.

Or something else?

What I'm saying is simple: there's the security of the code and the mitigation itself to consider. I know of no talented people interested in devrloping bypasses for OpenBSD mitigations since nobody uses OpenBSD. So, they break even more clever stuff in Chrome, Windows, etc. Given your example, lets change the mitigation to make it more obvious, though.

OpenSMTPD (email for short) is the target. Default are Windows, Linux, and OpenBSD on x86. OpenBSD devises a mitigation: use SPARC processor since x86 malware cant work. As you say, the malware works on everything but the SPARC box. You and others claim it means the mitigation is secure and so is what uses it.

Now, some guy named Nick claims it's no more secure than a BSD/Linux 0-day on x86: they just didn't target exploit for that environment. Sure, they have to learn SPARC ISA and how OBSD uses it. Sure there's work involved. Similar mitigations were beaten in the past by first person willing to invest effort, though. So, Nick posits reason SPARC is safe from x86 malware coders is that they don't care enough to deal with SPARC boxes. Maybe no market share.

See how that works now?

Whats the term, security by obscurity?

Basically. Now, it's fine to throw in obscurity or unusual mechanisms on top of good security practices. I used that to stop high-strength attackers before. Yet, we must be careful to note the difference between these mitigation results:

A. We stopped those vulnerabilities from working because nobody can bypass this mitigation.

B. We stopped those vulnerabilities from working because very little talent is working on beating our mitigation.

World of difference there as Chrome and SFI/CFI teams I linked up above found out when smart hackers and braniacs from CompSci began convergjng on their work. And shredding it.

Code-Pointer Integrity was last one standing after first round of peer review. I'll use it for medium-assurance if it survives 2-3 more. Check it out.

>If you had the same version of OpenSMTPD running on a generic Linux kernel or on Mac OS X, it was vulnerable

You're completely wrong, stack canaries have nothing to do with kernels, they're a compiler option, gcc has them enabled by default, clang has them enabled by default. So no, running OpenSMTPD on Linux or OS X would not make that vulnerability exploitable.

> thanks to CompSci ...

Dumb question: Do you mean the field of computer science in general, or some specific tech or organization that uses that name? The former doesn't exactly make sense, but I've not heard of the latter and would be interested ...

It's not a stupid question since I never define it. :) I had an extended discussion/debate with Kragen a while back on engineering software vs programming it. Many in academia and industry came up with methods to do software like a form of engineering with great results in practice. Sometimes even proving its properties. Whereas, programming was anything from throwing crap together to carefully constructing it in a way that uses a subset of engineering concept. I eventually realized we were tripping over definition of "software engineering" since people on his side of fence had that forever tied in their mind to groups pushing processes and Big Methodologies over good code. He kept referring to CompSci so I decided to use it to represent top work out of academia on engineering software to avoid red-flag phrase of "software engineering."

In any case, I can give you some links to illustrate engineering software vs merely programming it. The first gives the concept with good analogies showing why we need it and what the difference is. Others are examples of methods for doing it.

What is High-Assurance and Software Engineering? http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt

Cleanroom Software Engineering http://www.engr.mun.ca/~dpeters/7893/Notes/presentations/Cle...

High-assurance CA with Altran/Praxis' method http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...

Hope these help illustrate what I mean by engineering software. Although, my use of the CompSci term includes anything else scientific or cutting-edge that's coming out of academia. I'll toss in one more showing secure browsing done right (maybe). :)

https://www.usenix.org/legacy/events/osdi10/tech/full_papers...

Thanks!

An example of Linus' attitude:

> Nobody really objected to the patch series as a whole, but Linus hated the name of the configuration option; he asked that it be called CONFIG_LEGACY_VSYSCALLS instead. Or, even better, the change could just be done unconditionally. That led to a fairly predictable response from the PaX developer on how the kernel community likes to hide security problems, to which Linus said:

>> Calling the old vdso "UNSAFE" as a config option is just plain stupid. It's a politicized name, with no good reason except for your political agenda. And when I call it out as such, you just spout the same tired old security nonsense.

https://lwn.net/Articles/446528/

I think this line was meant mainly to refer to his closed source iPhone, OS X, and Windows use. Perhaps he means his Linux usage is one of the more mainstream distributions that readily facilitates installation of binary kernel blobs (e.g. wifi, video), or 3rd party closed source software.

He may also be calling Linux insecure due to it being less uncompromisingly about security. Same could be said about FreeBSD--they aren't necessarily insecure, but they are not as explicitly focussed on that.

OpenBSD invests a great deal here. They have their own fork of Xorg (or was that XFree86?) that runs not as root. As far as I know that's unique amongst libre *nixen.

EDIT: this is what I get for starting a response, getting coffee and resuming my reply. We don't have to speculate what the author of is post intended, and his response is better than mine ;-)

> OpenBSD invests a great deal here. They have their own fork of Xorg (or was that XFree86?) that runs not as root. As far as I know that's unique amongst libre *nixen.

It's a standard feature of Xorg nowadays, but it's only a feature of vanilla Xorg for a few years.

I'm probably misunderstanding something but on my system (Ubuntu 14.04 LTS) the X server runs as root & not as my user.

Ubuntu does not enable it by default, as it mixes poorly with some drivers: https://wiki.ubuntu.com/X/Rootless

AMD only added KMS to their proprietary driver last year, and Nvidia this year (and IIRC only in a beta driver so far); and systemd makes the permission handling a lot easier. So Ubuntu will transition to it eventually, but didn't have all puzzle pieces until too recently for even 16.04 LTS.

FreeBSD is pretty anti-secure too. https://vez.mrsk.me/freebsd-defaults.txt

Also this: http://networkfilter.blogspot.com/2014/12/security-openbsd-v...

BSD Now did a rebuttal in Episode 134 http://www.bsdnow.tv/episodes/2016_03_23-marking_up_the_port...

IMHO, I found it unconvincing. It soured me on the rest of the episode and its not really my watch as soon as its out podcast anymore. I guess since every segment is basically a FreeBSD segment no matter what OS they are talking about, it had to go that way.

YMMV

why not freebsd? the freebsd project seem to focus exclusively on post-attack with jails and trustedbsd mac. fbsd has not implemented any of the modern exploit mitigation techniques. i mean, even os x has had full aslr since 2012 lol.

some years ago fbsd was forked to hardenedbsd which has aslr, mprotect restrictions, non-exec pages on cpus w/o NX, randomized lib loading order, etc. i guess the freebsd project is too busy fighting meritocracy cus none of it has been merged as far as i can tell.

as for linux, plenty has been written on linus' stance on what he considers to be a "security circus"; and the mantra on lkml is still that "a bug is a bug". just watch oss-sec and see distro people wading through kernel commit logs (hyperbole) cus sec-related bugs usually aren't reported downstream

FreeBSD has ASLR. https://wiki.freebsd.org/AddressSpaceLayoutRandomization

no. did you read the first paragraph?

> FreeBSD lacks basic low-level exploit mitigation, such as Address Space Layout Randomization (ASLR)

the whitepaper you linked was published in 2014 by Shawn Webb, one of the people behind the hardenedbsd fork. that same year a submission for review was opened on phabricator[1] re. merging their aslr work in mainline fbsd.

it was closed on 2015-10-19:

> Closing this revision. FreeBSD is free to pull from HardenedBSD.

another aslr review request was then created on 2016-03-10 by Konstantin Belousov[2]:

> This revision needs review, but there are no reviewers specified.

that same day he sent a call for testing to freebsd-arch[3].

there is also a bugzilla ticket[4] for the people waiting for freebsd to catch up with 2001.

1: https://reviews.freebsd.org/D473

2: https://reviews.freebsd.org/D5603

3: https://lists.freebsd.org/pipermail/freebsd-arch/2016-March/...

4: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181497

FreeBSD lacks (or disables) most mitigations OpenBSD (and usually Windows, or some Linux distros) have, like ASLR, stack protector, W^X, PIE applications by default, libc.so symbol randomization, pledge()'d ports, etc.

I love FreeBSD, and use it a lot, and I wish these were all implemented, but until then, it pains me that FreeBSD has less mitigations enabled than Windows and good Linux distros.

Since OpenBSD can be backdoored[1] with the same ease that the Linux kernel could be backdoored, I have no idea why all the fuss. Debian is pretty thorough in NOT including proprietary software if that's what we're talking about.

As far as I'm concerned, it's good to have options and the OpenBSD developers have created software that I use daily (OpenSMTPd, SSH, PF, etc.) and for that, I'm thankful!

ps. I know that developing IPSEC backdoors is not easy by any means. But the subsequent Theo De Raadt answer, was that he can't tell if there are backdoors or not. That was my point.

[1] https://marc.info/?l=openbsd-tech&m=129236621626462&w=2

>can be backdoored[1] with the same ease

No, no with the same ease. Every OpenBSD commit is throughly reviewed, and there is only a bunch of commiters. Compared with linux, with thousands of commiters and tons of code added every day, OBSD is way more difficult to backdoor.

No loadable kernel modules for OpenBSD either.

Not having a formal kernel module system does not actually mean the kernel is secure. Exploits to create module loading systems out of kernel vulnerabilities are approximately as old as stack overflow exploits.

NX enforced kernel W^X, SMEP/SMAP, always-on stack protector and a limited attack surface (..say, from pledge(2)), only serve to make such theoretical attacks impractical against OpenBSD.

No. Those are useful countermeasures, but kernel exploits for OpenBSD are neither theoretical nor impractical.

Even as an OpenBSD fan, I'm not sure why tptacek was downvoted here. W^X etc. make it harder to write an exploit, but sufficiently-bad bugs can still yield arbitrary code execution. (Or confused-deputy problems allowing escalation to root, etc.; there's more than one way to pwn a box.)

And - architecturally - OpenBSD's kernel isn't that different from Linux, both being UNIX-style kernels; to the extent that OpenBSD's kernel has better security than Linux, it's mostly because OpenBSD tends to have fewer (and, sometimes, better-considered) features.

(There's an interesting argument to be had about Linux+grsecurity vs. OpenBSD - focusing on having some cutting-edge parts vs. solid engineering throughout - but that's not the argument we're having.)

I'm not sure why tptacek was downvoted here

Maybe because his comment had the tone of:

"For this, I have found a truly wonderful proof, but the margin is too small to contain it."

Do you need a "truly wonderful proof" for "the mainstream OS OpenBSD has not managed to render kernel vulnerabilities unexploitable, or to rid itself of those vulnerabilities entirely"? Because: that's an extraordinary claim for an OpenBSD supporter to make.

I was not responding to "the mainstream OS OpenBSD ...". Let's go back to your remark, which preceded his:

kernel exploits for OpenBSD are neither theoretical nor impractical.

You put that out there as a bare, standalone statement. No elaboration, no proof.

Your comment might be true, but I would have liked to see some more "meat" in it. Some supporting evidence, some inkling of a truly wonderful proof.

I did write a remote kernel exploit for OpenBSD, it was not an easy task, and this was in a time when there were basically no exploit countermeasures in kernel (2007) (https://www.coresecurity.com/content/open-bsd-advisorie)

There are a bunch of local kernel exploits, all very practical and reliable. Kernel protections are something OpenBSD lacked until very recently.

Yes, thanks for reminding me of that one.

That timeline isn't pretty. The OpenBSD guys really needed to be dragged, kicking and screaming, to calling it a "security fix" rather than something milder like a "reliability fix".

I'm glad you're saying it, too, as I get tired of this myth. I wrote a scheme on Schneier's blog for disproving it a while back. Basically, you counter the mitigations which look awfully similar to the one's that got countered in Linux and Windows. Once you have that, wait until a bug is mentioned on mailing list that can lead to memory attack. Weaponize it. Profit.

Leads me to what I claim is dirty secret behind "only 2 holes in..." claim they have: OpenBSD just fixes bugs they find without serious attempts to determine if they'd be exploitable vulnerabilities. They just do accounting differently than the rest. So, by their numbers, they only had 2 vulnerabilities because they didn't assess whether other bugs were vulnerabilities in the first place.

They have good code quality but they're full of shit about how vulnerable it is or isn't.

Note: they explicitly state "only two remote holes...", one of which can be found in this very thread.

Security problems are usually clearly marked in the changelog: http://www.openbsd.org/errata59.html

What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release.

For a normal user that's fine, but if you have a bunch of servers you'll need a sophisticated build/deploy infrastructure to stay updated.

That means no Internet-facing service has ever had a bug of the sort that often becomes code-injection. Or they didn't test for exploitability in the case of mitigations being bypassed. Neither one makes the claim stand up as it has hidden implication of "only two remote holes for amateurs and people ignoring mitigations."

"What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release."

Yeah, that sounds like it could be annoying. They should have both options available given they already have to trust OpenBSD team to not backdoor their stuff.

"Only two remote holes in the base install". That's because the base install contains very little in terms of remotely accessible services (only OpenSSH I believe?).

> Every OpenBSD commit is throughly reviewed, [...]

You should observe that this didn't happen here.

Sam Leffler found that bug, fixed it, and sent OpenBSD the patch while bringing the "fast IPSec"stack to FreeBSD.

OpenBSD silently patched it.

The whole thing only came to light years later, when the accusations were made.

>You should observe that this didn't happen here.

I bet it now happens.

you bet? yet in your previous comment you stated it as a fact

yes.

>Since OpenBSD can be backdoored[1]

And you link to that not happening? Seems a bit silly.

Reply on news.ycombinator.com