Is OpenBSD actually insecure or is it being insecure just a meme?

...

Other urls found in this thread:

mickey.lucifier.net/stories/b4ckd00r.html
linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true
cnet.com/news/report-of-fbi-back-door-roils-openbsd-community/
arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/
cryptome.org/2012/01/0032.htm
allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
aboutthebsds.wordpress.com/2013/01/25/20/
marc.info/?l=openbsd-tech&m=129244045916861&w=2
youtube.com/watch?v=LApw0YHibzk
youtube.com/watch?v=rRg2vuwF1hY
marc.info/?l=openbsd-misc&m=104570938124454&w=2
zerodium.com/program.html
undeadly.org/cgi?action=article;sid=20180115073406
openbsdfoundation.org/contributors.html
wiki.postgresql.org/wiki/SEPostgreSQL_SELinux_Overview
cr.yp.to/qmail/qmailsec-20071101.pdf
lists.dragonflybsd.org/pipermail/users/2015-August/228324.html
kristaps.bsd.lv/acme-client/
qualys.com/2015/10/02/opensmtpd-audit-report.txt
twitter.com/NSFWRedditVideo

mickey.lucifier.net/stories/b4ckd00r.html
linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true
cnet.com/news/report-of-fbi-back-door-roils-openbsd-community/
arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/
cryptome.org/2012/01/0032.htm

It was never admitted anyway.

Well, shit.

I wasnt going to share this but whatever
allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
aboutthebsds.wordpress.com/2013/01/25/20/

marc.info/?l=openbsd-tech&m=129244045916861&w=2

it's fud, don't worry

>cnet
>arstechnica
>cryptome
No, is not fud

>It was never admitted anyway.
No one ever found anything though (source code is available).

Go ahead, find some exploits in OpenBSD and become famous in the security researcher sphere. Go on then.

>implying

youtube.com/watch?v=LApw0YHibzk

youtube.com/watch?v=rRg2vuwF1hY

What's your point, he found some bugs and reported them, they got fixed. I see bugs fixed on my linux box every day. Now, how about some exploits.

>no exploits in the base os
>implying the base os is the most useful part of the machine

even intel did not bother to tell them about spectre. fuck bsd

Oh you're going to move the bar then? Well besides the base kernel and userspace most software available on a machine will be the same on OpenBSD or Linux. Don't forget that OBSD has their own fork of X and their own window manager in base, and ship useful tools like tmux in base which even Ubuntu doesn't do.

So that's quite a lot of software that falls under "base" in OpenBSD, and the software that's not base is the same software that ships with Linux. So what's your point again?

That a computer with only administration tools, basic UI, no network services, and no third party software is not useful in year of our lord 2018.

Critical exploits were demonstrated in 2017. What's special about these was they were more than a decade old. It's on the ccc website, "are all the bsds created equally?". Fact is there's precisely nothing difficult about finding gaping-huge security holes in openbsd. When they are fixed, if ever, the openbsd team refuses to assign a cve number so that they can keep lying about how secure they are, much like they redefine the word blob to pretend they don't have proprietary blobs.

Openbsd has no security measure in case there is an exploit anywhere on the system. If you install anything not in base, you're less secure than windows 95. If you do only use stuff from base and there's any exploit anywhere in there (protip: there are), you're as secure as windows 95.

it is the most useful part of the machine
OpenBSD base includes webserver, load-balancer, TLS proxy and certs management tools, CARP, SSH, ntpd, bgpd, smtpd and spam filter, ipsec+iked for VPN, shitload of network utilities

>implying any of the neckbeards here bother figuring out how to use openBSD which has no handbook or wiki but a bunch of man pages

I beg your pardon, that base system can be a firewall, DNS, mail server, web server, web proxy, load balancer, router and others. It includes tcpdump, netcat and many important sysadmin tools, none of which come in the base of RHEL or Ubuntu. The audited base also includes X and CWM.

Shut up you.

Not true friend, both OpenBSD and FreeBSD have excellent documentation online with examples.

Your hurt reddit butt should be tended to lest it ends up rotting off like your brain did.

Fuck dude you got rekt kys.

>tfw read 3 openbsd books already
>not even using it

Some software bugs were found, no remote flaws.

Every time I read one of those blogs I can't help but practically roll my eyes out of their sockets.

I feel the same, a whole lot of theories but no proof. I understand where they are coming from because in theory, MAC does provide a lot of control. To give credit Ubuntu did try to use MAC-lite apparmor to control firefox but I see that's now disabled. That would have been a good example of a big exposure controlled by MAC but even this well-known, ubuntu core app is just too much work to maintain. I'll give ubuntu the benefit of the doubt that it's back to WIP due to the switch to quantum.

But anyway the pragmatic approach of OpenBSD brings a new perspective and the techniques have proven to be robust despite the autismal academics screeching about it. strlcpy continues to prove its value for low-hanging bugs and gaining widespread use outside OpenBSD despite the glibc retards *still* not accepting it.

If you don't agree, feel free to use FreeBSD or Linux and their extensive security mechanisms which turn out to be total theatre in light of MELTDOWN, but I reckon you'll end up like every other overworked sysadmin who just turns that shit off because it's making his phone ring.

The blob thing is valid though. Whether or not your hardware is running binary blobs, the OS is not. It also ships without them. Upon the first boot it runs fw_update, which downloads only the blobs required for installed hardware. If you want a blob free machine, get hardware that doesn't require it.

The OpenBSD official fix for meltdown is to throw that Intel shit in the trash where it belongs. 100% mitigation.

*fuck Intel

This

If they still want to believe that claim is up to them, OpenBSD is free software and unlike many projects it's constantly audited and developed. Just this mail from Theo illustrates the huge amount of work that goes into these type of things.

marc.info/?l=openbsd-misc&m=104570938124454&w=2

No one writes exploits because no one runs OpenBSD.
There is no market for *BSD exploits
zerodium.com/program.html

>be pledged program
>can only read files and write to a socket
>instead of reading the requested file, reads your private files and send them over the network anyway

Pledge is not a proper sandbox. DJ Bernstein wrote a paper where he explains the difference between useless sandboxes like pledge and real ones (like Capsicum supports).

Attackers will exploit whatever service you're running (nginx, some PHP blog, whatever) and then do local privilege escalation.

That's how most exploits are structured nowadays; remote code execution + local privilege escalation

zerodium.com/program.html

If your 3rd party support constantly brakes, you have to write your own half baked tools to make it remotely usable. Aside openssh, nobody cares what they do. Even they have their own sound server so the system itself can provide autistic screeching too.

Taking a break from /biz/?

ive never seen a thread filled with so much bullshit

That's pretty funny as they claim being secure and having high standards. I wonder if their base system can compile with -pedantic-errors or whatever shit the clang equivalent for that.

Spam reported.

Did you read that on a blog?

Still haven't even patched for Meltdown, so yeah, it's insecure as shit.

I don't know and it's probably near impossible to know for sure, but they're the only semi-mainstream OS development community who give the finger to all companies with proprietary drivers and NEVER compromise on their values for hardware support, commercial support, etc.

meanwhile everyone else backtracks on their "fixes"

Bullshit, they will improve on their fixes, the most important thing was to stop the vulnerabilities, not produce the most elegant solution which is what they will do now.

Meanwhile OpenBSD doesn't even have a rudimentary fix, it's fucking wide open for attack, and they have security as their reason for being, it's laughable.

bizarro universe

...

...

Still better than no fix.

No, I actually know about security.

If I want to break into a system I'm going to attack the application layer first, because it's typically more complicated and changes more frequently, and thus more vulnerable (i.e. easier to break into Wordpress than into the TCP/IP stack).

From there, either that's all you need (if I break into Wordpress I might access unpublished data, etc.) or you will escalate using local privilege escalation vulnerability. OpenBSD does little to protect against that.

Its security models dates back from the 80s when you were running maybe 10 different services on a single box. But no one does that anymore. So quite often you don't need root access at all (unless you want to scrub logs).

You're typically running a virtual machine on top of your OS (Java, Python, PHP, etc.) OpenBSD will make sure you can't get out of that, but it doesn't really matter because all the important stuff is inside that sandbox.

Proper sandboxing would isolate at the resource level (i.e. file, socket, etc.) Pledge() helps but it does not fundamentally address the issue. If you have a program that can read a file and write to a socket, pledge won't prevent an exploit from sending the wrong file to the wrong recipient. There's a good paper by DJ Bernstein on that (it's called 10 years of qmail or something like that).

...

OpenBSD does not run properly on KVM, does not run on Xen, etc.
So perhaps it's not as critical as OSes people actually use to do actual stuff.

>Still better than no fix.
if only i got a dollar every time openbsd was first.

>security as their reason for being
way to shift blame. anyone not retarded will read the lists for the truth.

>having no working computer is better than nothing
Never change.
undeadly.org/cgi?action=article;sid=20180115073406

>WordPress

You don't know shit kid.

thank you

openbsdfoundation.org/contributors.html
:^)

It's also last for many things.

* No TRIM support
* Slow file system ("soft updates are supported but don't enable them because they're not quite reliable on OpenBSD")
* Generally slow everything (good luck getting 2 Gbps of your 10 Gbps network card)
* They were the last to offer binary updates and signed updates

Matt Dillon from DragonFly has better insights about security than OpenBSD people.

>not reading the file in an unprivileged chrooted process
>not transferring data to the network process via a strictly audited IPC interface
>not dropping the inet pledge after opening your socket
OpenBSD's system of privilege separation and privilege dropping is excellent and combined with pledge does exactly what you accuse it of not doing.

Enjoy your 10 capsicumized programs instead of the hundreds of pledged programs in OpenBSD (the majority of which can't open a socket thanks to strict pledges anyway).

> i just want to argue

These are botched Spectre microcode fixes from Intel, Meltdown which is by FAR the most dangerous vulnerability is fixed in the kernel everywhere but in the BSD's (well, apart from DragonflyBSD which is insane given that it's is a one man show).

Replace Wordpress by any other application, my point remains.
I picked Wordpress because it's insecure shit, but it could be some Java/Spring app, Python/Django or what have you.

OpenBSD offers virtually zero support for securing applications. Because it's based on the old Unix security model, root/not root. What you want is low-cost, OS support for isolating resources (users, connections, etc.)

See wiki.postgresql.org/wiki/SEPostgreSQL_SELinux_Overview
Good luck achieving anything like that with OpenBSD.

That shit is still a bit experimental and not enabled by default in FreeBSD and Linux, but it's there.

openbsd ships with secure services, secure and simple. if you want to roll your own facebook using random shit in ports, that is not what openbsd is intended for.

The pledge() model helps reduce the attack surface, so it's better than nothing, but it doesn't really address the issue. And in any case it's not really a sandbox.

If you have a (pledged) program that can read files and write to a socket, it can read anything and write anywhere. Sure, it won't delete a directory, but it won't prevent someone from stealing your data. I.e. it's not really sandboxed.

Read this paper: cr.yp.to/qmail/qmailsec-20071101.pdf (especially part 2.5)

i don't know about all that, but I'll give you the benefit for now

it's a meme started by people who were obsessively irate following theo being rude in response to their stupidity

>Meanwhile OpenBSD doesn't even have a rudimentary fix

Maybe read the mailing lists, instead of spreading your bullshit to others.

...

at least it was written by people who care about security

>even have a rudimentary fix
yeah. i'm sure they're not working on it and are instead eating avacado toast sitting around in bean bags

>thinks he can root openbsd via wordpress

Go on then, I'd be impressed. I'll even let you use a version with known vulnerabilites which shouldn't be that hard to find.

Matt Dillon is a KEK. I remember when he was charging people to use his shareware compiler.

even if, admin your shit. if you're running something not in base for whatever reason, admin it yourself, or pay someone, or do your job.

Ok then you stupid cunt. You're just blowing smoke. I'll let you get back to your blog comments, because you wouldn't dare go and discuss any of this on the openbsd lists.

i wasnt arguing with you. not that guy you were asking.

secure as long as you dont install any additional programs on it

...

but yeah, i wouldn't go to lists and say, "why don't you ship wordpress"

You did not even read what I wrote. My point is that root does not really matter.

Maybe because the store where he buys his food and his landlord also charge for their stuff.

I can't tell if you intentionally jumped over my discussion of privsep/privdrop or not. OpenBSD's development practices that I mentioned don't just fall under djb's ยง 2.5 because he talks about "[having] the power to violate the user's security requirements". OpenBSD does enforce security requirements: not with MAC or ACLs, but through traditional Unix mechanisms combined with kernel features like pledge. Can a process "read anything" once it's been chrooted and pledged rpath (file read)? Can a process "write anywhere" once its sockets have been opened and the inet pledge is dropped?

Pledge is simple: call this function, and you're limited to the syscalls you asked for. Call it again, and you get even fewer. How many software developers or sysadmins are capable of compiling an existing SELinux policy, let alone writing their own?

It's not "there" yet. I agree that the isolation has to be low-cost. pledgepath() is under development; I'm looking forward to restricting a bunch of programs that are currently pledged only with file read/write/create and stdio to particular paths.

Moving the goalposts? KYS.

>and they have security as their reason for being
I was under the impression that they really only cared about code correctness.

Anything that's not formally verified is insecure.

Indicate a single bit of public internet that is EAL7.

Pledge prevents nonsensical stuff (e.g. tcpdump creating a directory), but it doesn't implement a proper sandbox around resources that would prevent from violating the user's security requirements (read djb's paper again).

Let's say I pledge() an office building:

* Only people can enter the building (not cars or elephants!)
* Only people can enter the lifts (not office desks or chairs!)

It still doesn't prevent a robber from entering the building through the door, taking the lift to floor 8, stealing some documents, and leaving.

Similarly, think about how a browser is pledged. You can still read and write files into your home directory, and connect anywhere. I.e. some rogue JavaScript can still steal your files, and thus violate your security requirements.

You can pledge() OpenSMTPD, but I find a bug I might still be able to steal your email, even though I won't be able to get root, or create a directory somewhere.

You need something that is more fine-grained and can work with individual resources, like capsicum. Maybe pledgepath() will be a step towards that.

>Anything that's not formally verified is insecure.
Anything that has not been formally verified just hasn't been formally verified.

Maybe learn what security is. It's about protecting certain resources, not necessarily protecting the fucking root account.

>Anything that has not been formally verified just hasn't been formally verified.

Ergo it's insecure.

No. You can't prove that it's secure, but you cannot declare that it is insecure either.

You need a proof either way; i.e. either a formal proof or an exploit. If you have neither all you can say is "we don't know".

>Ergo it's insecure.
Software isn't necessarily insecure if it hasn't been formally verified user. In fact what if I told you that all the software that hasn't been formally verified was secure before they were formally verified.

I get that. I've run my browsers as a few separate users and tightened read permissions on my box ever since the Firefox PDF hack: lists.dragonflybsd.org/pipermail/users/2015-August/228324.html

Chrome is pledged on OpenBSD btw. Like I said, I'm looking forward to pledgepath and this is one of the reasons why. If I were really paranoid I would run it in vmm or something in the meantime.

The trouble is this kind of security can't be generalized. Generalize it and you get jails or virtual machines which are the opposite of granularity. If you privilege separate your apps properly, it mitigates most of the harm.

For example, see OpenBSD's Let's Encrypt client. It has a nice description of how it uses privsep and pledge to keep things isolated. kristaps.bsd.lv/acme-client/

This kind of design has real benefits. OpenSMTPD is an example of a daemon that had some serious and pretty embarrassing bugs -- but the structure of the program combined with the operating-system level protections mitigated a lot (no, not all) of the real-world harm. Well-thought-out privsep design and OpenBSD's fairly pedestrian mitigations like stack canaries and ASLR were a significant benefit even to a codebase with some big problems. (It also reinforces the importance of practicing security auditing.) qualys.com/2015/10/02/opensmtpd-audit-report.txt

What I'd like to see is virtual desktops that run as different users.

This way I can have a desktop for Sup Forums, porn, etc., a desktop for work, a desktop for personal stuff like online banking, taxes, etc.

Different users, no copy/paste between desktops, but easy to switch.

In principle it's not difficult to implement, yet I have not seen a system doing that. Qubes OS does something slightly similar but at a different granularity.

?

You're implying pledge is the only safeguard and looking at Mac as a panacea which is where it fails. Your SMTP example ignores that openbsd mailer is privsep, chroot and has multiple stack protection and audited.

You can do that easily. Manually start X on different consoles, or use the user switching available to most modern desktops, or just su user and xhost access them.

Yeah, that would be pretty sweet.

I'm not saying that the mitigations in OpenSMTPD are useless, but they're only based on preventing the software from doing operations it should never do (execute code on the stack, flush PF rules, restart DHCPD and so on).

OpenSMTPD can still send email; i.e. if I find a bug I might still be able to forge email or read your email. So what you want is sandboxes around the *data*, not around the software components (the privsep model). I.e. after sending MAIL FROM and RCPT TO to an SMTP server, I want sandboxes around those objects. If there is an exploit, the worst I can do is send emails to the RCPT TO addresses. Thus I cannot violate any security requirement. This is what djb is alluding to in the paper linked before.

Right now no one really has that anyway, but the few people trying are in the FreeBSD, Linux and Windows camps, with capabilities and similar mechanisms. Thus I assume they'll be there first.