Authentication Vulnerabilities in OpenBSD(openwall.com)
openwall.com
Authentication Vulnerabilities in OpenBSD
https://www.openwall.com/lists/oss-security/2019/12/04/5
92 comments
Oh, wow, this is brutal. They're shelling out to a command line program to do authentication, and not catching the "-" metacharacter in the username they shell out with, so you can pass options to that program.
This feels like an old school vulnerability. Things like this were the norm in the 90's and early 2000's. It feels weird to see an exploit like this now in a large and well known project, and very weird for it to be in OpenBSD.
It just goes to show, as a user you can make informed choices in what software to use to reduce your security exposure, but that's not enough. You still need to pay attention to new problems that might pop up. No software is guaranteed to be safe in perpetuity.
It just goes to show, as a user you can make informed choices in what software to use to reduce your security exposure, but that's not enough. You still need to pay attention to new problems that might pop up. No software is guaranteed to be safe in perpetuity.
In a world where we harden all of the things and write code in memory safe languages maybe memory corruption will be the old school vulnerability and this type of thing will be all that is left
Yep, there will always be parsing bugs like not sanitizing input, logic failures, weak algorithms, timing attacks, ...
That's why I like DBJs method. You still use a command line program, but you pass a filehandle that the authentication data can be read from.. this seems much safer than trying to parse and re-format that data as an intermediary. Also avoids any data leaks through the often unprotected 'cmdline'.
Is there some technical reason OpenBSD doesn't do this?
Is there some technical reason OpenBSD doesn't do this?
Thank God for DJB. His entire website should be required reading for software developers.
Thanks for the recommendation, I'd previously heard of DJB but was unaware of his writings.
Here's the link to his website: https://cr.yp.to/djb.html
Here's the link to his website: https://cr.yp.to/djb.html
I am convinced that DJB is actually the reincarnation of John von Neumann.
Seriously, how many other people make contributions in areas ranging all the way from number theory to hand-written machine code?
Seriously, how many other people make contributions in areas ranging all the way from number theory to hand-written machine code?
Probably historic compatibility. If making a breaking change this might be a good time to implement a design benefiting from decades of real world experiences.
That's literally what OpenBSD was doing over decades,
starting with binary compatibility
with Linux and a lot of legacy stuff
which came from NetBSD and BSD 4.4 lite/BSD 4.3.
You described OpenBSD with that comment.
- Xenocara with rootless privileges as a fork of X
- LibreSSL
- Linux compat going away
- Pledge/Unveil
- Some daemons belonging to ports
- HTTPD/SMTPD and so on as replacement of bloated daemons
- OpenSSH itself
- Retguard
This vulnerability is bad, but pledge
and unveil will have even
more prominent roles in base soon, so even
if you get privs, you can do either nil or just crash because of pledge.
starting with binary compatibility
with Linux and a lot of legacy stuff
which came from NetBSD and BSD 4.4 lite/BSD 4.3.
You described OpenBSD with that comment.
- Xenocara with rootless privileges as a fork of X
- LibreSSL
- Linux compat going away
- Pledge/Unveil
- Some daemons belonging to ports
- HTTPD/SMTPD and so on as replacement of bloated daemons
- OpenSSH itself
- Retguard
This vulnerability is bad, but pledge
and unveil will have even
more prominent roles in base soon, so even
if you get privs, you can do either nil or just crash because of pledge.
What does “DBJ” stand for?
DJ Bernstein, famous for remixing sendmail and similar hits in the 90s
I think he means Daniel Bernstein, a prominent cryptographer and coder.
Daniel Bernstein, author of qmail, djbdns, and daemontools among others.
And where does that auth-info-via-file-handle come from? I did a bit of duckduckgoing and couldn’t spot anything about that.
The qmail source code has this convention.
Thanks!
Some call the concept "Bernstein Chaining": http://www.catb.org/%7Eesr/writings/taoup/html/ch06s06.html
That's DJB. DBJs is a Javascript database thing. There is possible ambiguity here.
Fair point. I associate DJB with security and coding best practices, Javascript not so much. I can only hope the comment I replied to meant DJB the person.
I hope so too.
> They're shelling out to a command line program to do authentication
Interesting to track who exactly "they" might have been, as many commenters are saying this is uncharacteristic for OpenBSD.
Looking at the patch, the first OpenBSD commit of this file [1] is from 2000 and says "from BSDI" in the commit message, did fork()+execve() at that time, and the BSDI copyright comment says 1995-1997.
Probable to say more recent OpenBSD stuff is likely not written this way, but that they have baggage like this in the tree from earlier times.
[1] https://cvsweb.openbsd.org/src/lib/libc/gen/auth_subr.c?rev=...
Interesting to track who exactly "they" might have been, as many commenters are saying this is uncharacteristic for OpenBSD.
Looking at the patch, the first OpenBSD commit of this file [1] is from 2000 and says "from BSDI" in the commit message, did fork()+execve() at that time, and the BSDI copyright comment says 1995-1997.
Probable to say more recent OpenBSD stuff is likely not written this way, but that they have baggage like this in the tree from earlier times.
[1] https://cvsweb.openbsd.org/src/lib/libc/gen/auth_subr.c?rev=...
There have been many bugs in NetBSD code that are found and fixed. Quite often these bugs are in code shared with OpenBSD, but you never see them list it as such, as they import said fixes from NetBSD.
edited: make verb plural.
edited: make verb plural.
Yeah. It's a shame how few people invoking shell commands use tricks like "--" to suppress option parsing and "./*" to suppress bad globs. :-(
Yep, very cool.
> We thank Theo de Raadt and the OpenBSD developers for their incredibly quick response: they published patches for these vulnerabilities less than 40 hours after our initial contact.
Awesome.
Awesome.
> this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.
Does this mean OpenBSD will have to update the tagline on their website that says "Only two remote holes in the default install, in a heck of a long time!"?
Does this mean OpenBSD will have to update the tagline on their website that says "Only two remote holes in the default install, in a heck of a long time!"?
Most of the issues are classified as Local privilege escalation, and none of the daemons mentioned are enabled by default, sshd can be enabled in the installer, but as the quote says "sshd is not exploitable thanks to its defense-in-depth mechanisms."
So, no. Still holds.
Worth pointing that Linux has had a rough week as well, this one is pretty bad: https://www.openwall.com/lists/oss-security/2019/12/02/2
Patch your systems.
So, no. Still holds.
Worth pointing that Linux has had a rough week as well, this one is pretty bad: https://www.openwall.com/lists/oss-security/2019/12/02/2
Patch your systems.
One could also say that this has been a great week for Linux, since all these problems have been caught
Once again, the "in the default install" line should be read as "as long as you don't do anything interesting".
None of my OpenBSD machines (on which I do things) are remote-holed by this.
Neither are mines. PF blocks everything from the beginning, and no service is listening remotely.
Heck, even for _outbound_ mail I have to create a rule for smtpd.conf.
Half of the HN commenters do not know OpenBSD at all.
Smtpd (one of the mentioned daemons) is started in a default install. It is configured to do local mail delivery and can queue up remote deliveries for programs running on the system. It only connects to localhost and does not authenticate so this exploit would be irrelevant. If one did open an authenticated mail connection on an interface accessible to the world then the exploit would allow the system to be used as a spam relay.
Added: Just to be clear, this doesn't give any significant access to the system itself through smtpd even if it is configured to be remotely accessible. So not a possible remote hole. Dunno about other stuff.
Added: Just to be clear, this doesn't give any significant access to the system itself through smtpd even if it is configured to be remotely accessible. So not a possible remote hole. Dunno about other stuff.
Yes, correct. smtpd is enabled on localhost for local users only. This is pretty common on most systems, AFAIK Debain uses exim4.
[deleted]
You need this line in PF at least:
pass in on egress proto tcp from any to egress port smtp
Uh, a bug disclosed from the infamous FVWM guy with a great default config.
This is amazing.
http://taviso.decsystem.org/img/screenshot.png
http://taviso.decsystem.org/img/screenshot.png
That you primarily know of Tavis from his FVWM config and not his security work is really weird.
Well, most people know Assange from politics and I knew him better from being the Surfraw author. To each its own, I suppose.
I thought so too, but then I saw the screenshot, and it's a pretty nice looking fvwm setup.
It's one of the best FVWM setups ever.
I am not trolling, he was cheered a lot
back in the day, everyone adapted
its config somehow.
I am not trolling, he was cheered a lot
back in the day, everyone adapted
its config somehow.
> back in the day, everyone adapted its config somehow.
Yeah I know, although I don't remember coming across Tavis's config I did live through those heady days of customizing window managers and remember them with fondness. [Although that screenshot has emails dated 2006, which puts it well after that culture had peaked.]
I actually started using fvwm2 again recently on one of my machines, I am not sure why, maybe I had some nostalgia for that time period.
Yeah I know, although I don't remember coming across Tavis's config I did live through those heady days of customizing window managers and remember them with fondness. [Although that screenshot has emails dated 2006, which puts it well after that culture had peaked.]
I actually started using fvwm2 again recently on one of my machines, I am not sure why, maybe I had some nostalgia for that time period.
I had a tweaked fvwm2 from OpenBSD's vanilla setup, but nowadaws the less code I type and debug, the better. That's why I use cwm and I almost never code in C or strip unneded settings, everything else is scripted with good enough performance.
Back in the day I patched dwm and then Surf to enable WebGL among other nice stuff thanks to gobject being brain-damagedly easy.
Nowadays I am too lazy: cwm, tmux, mpg123, mpv+ytdl, vimb/iridium, UBo, Vimium, HTTPS ev, Priv badger, and I call it a day.
Back in the day I patched dwm and then Surf to enable WebGL among other nice stuff thanks to gobject being brain-damagedly easy.
Nowadays I am too lazy: cwm, tmux, mpg123, mpv+ytdl, vimb/iridium, UBo, Vimium, HTTPS ev, Priv badger, and I call it a day.
This discussion comes up a lot, and I'd make an opposing case. Rather than debating whether OpenBSD can reasonably say this - I'd suggest most Linux distributions could say it themselves if they so wanted.
Last time I installed CentOS the only port open on the firewall by default with OpenSSH after all.
Last time I installed CentOS the only port open on the firewall by default with OpenSSH after all.
Yes, patch as often as you can but I note that link you provide looks like a local priv. escalation, ie you have to be able to login to the box in some way.
This OBSD bug is externally exploitable.
Why did you single out an obscure Linux bug? There are quite a few other OSs available apart from OBSD.
This OBSD bug is externally exploitable.
Why did you single out an obscure Linux bug? There are quite a few other OSs available apart from OBSD.
It's a few threads above the OpenBSD one on oss-security, hardly obscure.
https://www.openwall.com/lists/oss-security/2019/12/
https://www.openwall.com/lists/oss-security/2019/12/
By default? No.
"Default install" would be the key phrase here. By that metric, no need to update the tagline; smtpd doesn't do much by default, and SSH has other safeguards, so apparently a default install wouldn't be substantially impacted.
Still sucks for those of us who, you know, actually use smtpd on OpenBSD as a mail server. Thankfully it's just my personal one and I can afford to comment out the line(s) that actually enable outbound SMTP relaying, but still.
Still sucks for those of us who, you know, actually use smtpd on OpenBSD as a mail server. Thankfully it's just my personal one and I can afford to comment out the line(s) that actually enable outbound SMTP relaying, but still.
By default PF doesn't allow shit from external connections, so no.
Yes.
No.
How? Show me how can I, remotely:
- Login with no SSH account
- Enable SSH
- Change PF rules
- Change the smtpd config
- Enable radiusd/ldapd without being root
- Running Xenocara's xlock when is not available on servers and I have no permissions
- Login with no SSH account
- Enable SSH
- Change PF rules
- Change the smtpd config
- Enable radiusd/ldapd without being root
- Running Xenocara's xlock when is not available on servers and I have no permissions
This is an extremely silly set of conditions to attach to "remote hole". You can litigate it, and maybe win the argument, but you're just bold-facing the asterisk that was already next to that already-tortured claim.
You mean, overriding defaults as conditions to get a remote hole?
Can you exploit a bare OpenBSD install by default remotely, yes or not?
Everything else is bullshit.
Can you exploit a bare OpenBSD install by default remotely, yes or not?
Everything else is bullshit.
Security is not Boolean
By default you can only set two service settings: Enabling sshd, or not.
And sshd is, by default:
- not exploitable by this bug
- PF rules are not set for incoming connections
The X issue. By default:
- PF doesn't accept any connection to X ports to
anything not coming from lo0, localhost interface
Smtpd. By default:
- it just listens on localhost
- there is no forwarding
- PF rules aren't enabled
And sshd is, by default:
- not exploitable by this bug
- PF rules are not set for incoming connections
The X issue. By default:
- PF doesn't accept any connection to X ports to
anything not coming from lo0, localhost interface
Smtpd. By default:
- it just listens on localhost
- there is no forwarding
- PF rules aren't enabled
Show me, as the owner of the openbsd server, how to change the default configuration to suit a purpose that exceeds the very limited set of services enabled.
Upstream eratta and binary patches to address these issues is available: https://www.openbsd.org/errata66.html
The patch is still fresh so it's not distributed to most mirrors yet.
In case syspatch doesn't appear to do anything, check your /etc/updateurl, set it to the OpenBSD CDN, then run again.
In case syspatch doesn't appear to do anything, check your /etc/updateurl, set it to the OpenBSD CDN, then run again.
Important quote:
“this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.”
Edit: formatting.
“this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.”
Edit: formatting.
Yikes. This one just turned my mail server into an open relay (assuming any would-be attackers picked up on it running smtpd). Went ahead and shut off outbound mail delivery (so smtpd only accepts mail destined for my domain) until I can get this patched.
Kudos to the OpenBSD folks for getting a patch whipped up so quick, and thankfully SSH ain't affected, but Jesus.
Kudos to the OpenBSD folks for getting a patch whipped up so quick, and thankfully SSH ain't affected, but Jesus.
What's very cool about this to me is how well put this report is in layman's terms.
Also is this going to increment the "X remote vulnerabilities in X years"?
Also is this going to increment the "X remote vulnerabilities in X years"?
As long as you override a default PF install, go on. Because you can't. Even with a PF rule being set, you must set up smtpd.conf right.
Also no ldapd and radiusd is listening by default, and SSHD is secure by itself. And you are asked in the first install if you want to enable it at boot, btw.
Also no ldapd and radiusd is listening by default, and SSHD is secure by itself. And you are asked in the first install if you want to enable it at boot, btw.
Worth noting that this vuln passes you through authentication as an almost certainly invalid user - I expect the devs to put in more username validity checks, like the one ssh has, to mitigate this class of issues in the future.
(The second vuln listed is less sexy but escalates you to a real group.)
(The second vuln listed is less sexy but escalates you to a real group.)
Tangential, but it appears openwall.com is on several of my pi hole blocklists. I'm guessing its because of the tools they offer?
So... are they gonna update the OpenBSD webpage to say "only three remote vulnerabilities in a heck of a long time?" Do these bugs represent a vulnerability to real systems deployed in the wild, or are they more of a theoretical threat?
>/usr/X11R6/bin/xlock is installed by default
Most servers will not install Xenocara at all in order to avoid
most security and space issues, as a lot of them now are using
vmm(4) for testing purposes.
Also as xlock moved upsteeam, OpenBSD will stop importing xlock
and maybe the will implement a patched and pledge(4)d slock (with
some features such as passwd display as asterisks) as the
Xenocara's workstation locker.
If would not be weird at all. Today the default wm is FVWM because
of historical respect to BSD's/Unix, but the most common WM used
by OpenBSD fans is, by far, CWM, which came from evilwm.
As Xenocara was already a fork of X, having a patched slock as
"xenolock" would be the next logical step.
Because xlock(4) is a shitty security fest by itself. Not to
blame the OpenBSD developers, but the main project. It's full of
features and slock matches better the OpenBSD's philosophy.
Most servers will not install Xenocara at all in order to avoid
most security and space issues, as a lot of them now are using
vmm(4) for testing purposes.
Also as xlock moved upsteeam, OpenBSD will stop importing xlock
and maybe the will implement a patched and pledge(4)d slock (with
some features such as passwd display as asterisks) as the
Xenocara's workstation locker.
If would not be weird at all. Today the default wm is FVWM because
of historical respect to BSD's/Unix, but the most common WM used
by OpenBSD fans is, by far, CWM, which came from evilwm.
As Xenocara was already a fork of X, having a patched slock as
"xenolock" would be the next logical step.
Because xlock(4) is a shitty security fest by itself. Not to
blame the OpenBSD developers, but the main project. It's full of
features and slock matches better the OpenBSD's philosophy.
I'm a big OpenBSD fan, but the OpenBSD devs recommend you install Xenocara, otherwise its considered a non-default install.
Well, if it's a CLI based server I'd doubt X would be needed at all.
OpenBSD Amsterdam (A well known provider in the circle of OpenBSD users) doesn't enable X by default on its autoinstall file:
https://openbsd.amsterdam/setup.html
EDIT: It enables xbase.tgz but not the rest.
OpenBSD Amsterdam (A well known provider in the circle of OpenBSD users) doesn't enable X by default on its autoinstall file:
https://openbsd.amsterdam/setup.html
EDIT: It enables xbase.tgz but not the rest.
If you use sysupgrade, all sets will be installed, regardless of which sets were chosen during initial install.
They've even threatened to make just one big set since too many people are not installing all of them and then come ask for help .
https://marc.info/?t=156851721400002&r=1&w=2
They've even threatened to make just one big set since too many people are not installing all of them and then come ask for help .
https://marc.info/?t=156851721400002&r=1&w=2
Oh true, I forgot that. Still the bug is not remotely exploitable, but I always wanted to send Xlock to /dev/null and propose a patched slock as an alternative. If OpenBSD got evilwm/cwm in base, why not slock? If the problem is the lack of keypresses' feedback on the screen, that could be solved in a easy way.
Yeah, the "it's secure as long as you don't use it for anything" gets old.
Openbsd recommends installing all sets these days.