Hacker News Reader

Comment by procinct | Hacker News Reader

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

View on HN

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.

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.

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

You need this line in PF at least:

            pass in on egress proto tcp from any to egress port smtp

And maybe another one with submission instead of "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

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.

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

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.

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.

Also what a remote exploit could do against RH's sshd vs a hardened and pledged sshd under OpenBSD counts, too.

Red Hat's sshd is also hardened, and sandboxed using seccomp.

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.

By default? No.

It's a few threads above the OpenBSD one on oss-security, hardly obscure.

https://www.openwall.com/lists/oss-security/2019/12/

One could also say that this has been a great week for Linux, since all these problems have been caught

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

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

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.

This is a bit like whether Magneto can escape the Plastic Prison (yes or no) without Logan traveling back in time and altering the timeline.

Or Trunks killing Cell.

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

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.

Reply on news.ycombinator.com