[nickpsecurity]

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).

[neerdowell]

> 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?

[nickpsecurity]

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. :)

[neerdowell]

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

[nickpsecurity]

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.

[neerdowell]

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?

[nickpsecurity]

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?

[eugeneionesco]

>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.

[hackuser]

> 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 ...

[nickpsecurity]

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...

[hackuser]

Thanks!