
Authentication Vulnerabilities in OpenBSD - jwilk
https://www.openwall.com/lists/oss-security/2019/12/04/5
======
tptacek
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.

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

~~~
k_sze
What does “DBJ” stand for?

~~~
inferiorhuman
Daniel Bernstein, author of qmail, djbdns, and daemontools among others.

~~~
k_sze
And where does that auth-info-via-file-handle come from? I did a bit of
duckduckgoing and couldn’t spot anything about that.

~~~
simtel20
The qmail source code has this convention.

~~~
k_sze
Thanks!

~~~
zdw
Some call the concept "Bernstein Chaining":
[http://www.catb.org/%7Eesr/writings/taoup/html/ch06s06.html](http://www.catb.org/%7Eesr/writings/taoup/html/ch06s06.html)

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

------
procinct
> 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!"?

~~~
notaplumber
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](https://www.openwall.com/lists/oss-
security/2019/12/02/2)

Patch your systems.

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

~~~
notaplumber
Yes, correct. smtpd is enabled on localhost for local users only. This is
pretty common on most systems, AFAIK Debain uses exim4.

------
zdw
Upstream eratta and binary patches to address these issues is available:
[https://www.openbsd.org/errata66.html](https://www.openbsd.org/errata66.html)

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

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

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

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

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

------
rsecora
This is the new -froot!!!

[1][http://seclab.cs.ucdavis.edu/projects/testing/vulner/18.html](http://seclab.cs.ucdavis.edu/projects/testing/vulner/18.html)

[2][https://www.symantec.com/security_response/attacksignatures/...](https://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=22145)

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

------
themattress
Tangential, but it appears openwall.com is on several of my pi hole
blocklists. I'm guessing its because of the tools they offer?

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

~~~
ben_bai
sshd is mentioned (1.5) exactly because sshd did catch this and refused login.
So no, no remote exploit in the default install.

But it was close :)

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

~~~
adamrt
I'm a big OpenBSD fan, but the OpenBSD devs recommend you install Xenocara,
otherwise its considered a non-default install.

~~~
linusnext
Yeah, the "it's secure as long as you don't use it for anything" gets old.

~~~
anthk
Also, OpenBSD is pledging the usespace really fast, such as Firefox and
Chrome, among unveil.

Even mgba got patched.

I woudn't call that as "don't use it for anything".

