141–150 of 162 posts
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
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 pl…
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,…
Earlier quoted context omitted.
No. Those are useful countermeasures, but kernel exploits for OpenBSD are neither theoretical nor impractical.
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 "on…
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.
Earlier quoted context omitted.
> Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment on that. That caught my eye as well; lumping Linux in with Windows or even OSX is insulting in the extreme on the privacy front and only slightly less on the security front. To be sure, the focus on many Linux distros is not security at the f…
> Hell, can someone tell me if it's dead simple to install OpenBSD with full disk encryption? Dead simple. Full disk encryption on OpenBSD is a discipline of softraid(4). One bioctl command during the install will initialize a hard disk with true full disk encryption. When I say true, I mean, no separate un-encrypted /boot partition like LVM on LUKS requires.
Great opinion piece. I think this is mostly the opinion of anyone that really discovers OpenBSD and gets caught up in it. Security does matter, and the developers accept nothing less than what they want. My main problem with OpenBSD development is that all development is decided solely by the developers and there doesn't seem to be much care for what others want.. which is fine, they're doing all the work for peanuts…
I've seen this type of comments many times, in many different context, about many different open source software projects, and I never understood them. > all (OpenBSD) development is decided solely by the developers and there doesn't seem to be much care for what others want This implies this is not the case for every other project. To pick on your SMP performance example, Linux doesn't have better SMP because "devel…
Many projects have different approaches to development. Sure, many people work on bugs most of the time, but there are big decisions about where the limited resources are going to be spent on new features. Those are the ones that truly matter.
There are examples of amazing things people have just done on a whim, but that isn't truly a standard and much of those things are generally huge.
Earlier quoted context omitted.
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,…
Whats the term, security by obscurity?
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.
Earlier quoted context omitted.
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 "on…
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 s…
"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.
Earlier quoted context omitted.
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 d…
> 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 ...
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...
Earlier quoted context omitted.
"Since you are a security researcher, aren't a lot of people of "your breed" using Macs as well?" I use Linux, BSD's, and custom systems. From what I've gathered, the people using Mac's do it for usability and apps more than anything. The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel. The real benefit is…
> The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel. Is it necessary to ignore the microkernel choice? Isn't MacOS X -not- microkernel, even though (or "because") it uses an old version of Mach? [0][1][2] [0] https://en.wikipedia.org/wiki/Mach_%28kernel%29 [1] http://www.roughlydrafted.com/0506.mk1.html…
So, Mach is its own discussion of failure in and of itself. There was also a history... Trusted Mach, Distributed TMach, DTOS... of trying and failing to secure Mach using high-assurance methods. The security improvements in new Mac OS's, esp sandboxing and such, were actually recommended with that old research in mind. They realized the foundation wasn't going to be secured as it never worked in the past. So, they went for decomposition and isolation schemes for apps themselves plus IIRC integration of TrustedBSD mechanisms.