OpenBSD Recent Security Innovations

https://undeadly.org/cgi?action=article;sid=20190605110020

by elchief • 7 years ago

163 43 7 years ago

cmurf2• 7 years ago

Anyone know why this link works in Chrome but not in Firefox? I get Peer could not decode an SSL handshake message. Error code: SSL_ERROR_DECODE_ERROR_ALERT

snazz• 7 years ago

Works here on Firefox. Something to do with your internet connection or certificate store in particular?

newnewpdro• 7 years ago

Works in FF just fine over here.

sam_bristow• 7 years ago

Are you on running on Fedora by any chance? You might've hit this issue:

https://www.mail-archive.com/misc@openbsd.org/msg167825.html

cmurf2• 7 years ago

Yep, thanks.

adioe3• 7 years ago

see https://bugzilla.redhat.com/show_bug.cgi?id=1713416

cperciva3• 7 years ago

Wait, OpenBSD didn't have MAP_NOCORE? FreeBSD added that in February 2000... I always assumed that the other BSDs had long since picked it up.

Huh.

wahern• 7 years ago

Pretty sure they've deliberately kept it out on principle: better to encrypt swap, ensure permissions on core files are strict, etc, rather than hope all applications correctly set MAP_NOCORE on every bit of sensitive data. Sounds like it just became too inconvenient to avoid, though.

tedunangst4• 7 years ago

Deliberate makes it sound like we wanted secrets to appear in the core files. I don't think that's the case, but otherwise yes, there's been a certain amount of care to making core files secure.

Someone• 7 years ago

”better to encrypt swap, ensure permissions on core files are strict”

I don’t think that’s entirely true. A risk this mitigates against is that system administrators read a user’s most sensitive data when they help them debug a crash.

Encrypting the disk won’t protect against that.

Making the core dump owned by the user running the executable won’t, either, because a) the user will have to make the file readable by the system administrators to get help fixing the crash problem, and b) one can assume the system administrators have root privileges, anyways.

On the other hand, a) programs can’t know what a user’s most sensitive data is (for example, they might be writing in their diary), and b) why would users trust a program to protect their most sensitive data in that way, given that it doesn’t even manage to “not crash“?

tedunangst4• 7 years ago

Do you know of anything using it? I haven't seen it come up before.

notaplumber• 7 years ago

Survey says, in the past ~20 years..

https://github.com/freebsd/freebsd/search?q=MAP_NOCORE&unsco...

Pretty much bupkis. But still more than Capsicum!

cperciva3• 7 years ago

There's a few utilities in the FreeBSD base system which use MAP_NOCORE -- I think mostly as a "this isn't useful so don't waste time dumping it" flag: mkimg, sort, grep. The libsodium we have imported into sys/contrib also mention it, but I don't know if those parts of libsodium are ever used by the FreeBSD userland.

Grepping the ports distfiles on my laptop, I see MAP_NOCORE mentioned in Cython, rust, qemu, firefox, and thunderbird; again, no idea how it's being used in those.

In the interest of compatibility, can I suggest

    #define MAP_NOCORE MAP_CONCEAL

for now, and in the future if MAP_CONCEAL adds new functionality define it as MAP_NOCORE|MAP_CONCEAL_EXTRA? Since you have the capability to exclude regions from core dumps, you might as well expose it to programs which are aware of MAP_NOCORE.

PS. Linux has MADV_DONTDUMP and FreeBSD has MADV_NOCORE; I'd suggest handling those as well if you don't already do so.

mjg59• 7 years ago

https://codesearch.debian.net/search?q=MADV_DONTDUMP suggests MADV_DONTDUMP is used in various places, including OpenSSL.

jedisct1• 7 years ago

libsodium uses it.

anaphor3• 7 years ago

https://man.openbsd.org/pledge.2 is also pretty damn cool. It effectively lets you make your program use a least authority model of execution, and then you can grant it the capabilities it actually needs to run. I would love to see something similar on Linux (there is capsicum-linux, but it seems like it's abandoned).

rurban3• 7 years ago

Totally uncool and a dead end. Nobody else will do it that way. "The promises argument is specified as a string, with space separated keywords". caps as strings to be tokenized at runtime are slow, insecure and not validated at compile-time. Never trust a parser in core. This needs to be a bitmask of course. Don't let ruby programmers add OS API's.

gpvos2• 7 years ago

The intended ad hominem in the last sentence does very much not apply.

ksec• 7 years ago

What has it got to do with Ruby ?

enriquto• 7 years ago

Never trust a parser in core.

So, we have to part ways with our dear printk ?

roryrjb2• 7 years ago

So like seccomp? Or do you mean a simpler interface like pledge? I haven't really used the seccomp syscall or eBPF directly but I have used libseccomp (https://github.com/seccomp/libseccomp) successfully.

anaphor3• 7 years ago

seccomp and eBPF will let you build something like this but it does not do the same thing as pledge.

aomix• 7 years ago

The PROT_WRITE tweak is interesting. Being able to enforce a bit of Write XOR Execute behavior in Write OR Execute arenas is nifty. It took this change for me to read into W^X and exactly what it entailed because my naive understanding was that the new no-syscall-from-writeable-page behavior would be almost identical in effect to the strict W^X behavior.

Lt_Riza_Hawkeye• 7 years ago

If you have data you don't want written to a core dump, then MAP_CONCEAL will literally only help you if that memory is in an mmap'd region. If it's in regular old virtual memory, you're fucked.

So if you're going to add a flag to something to let users conceal a region of memory from a core dump, add it to madvise, adding it to mmap is just adding arbitrary restrictions on the programmer.

Linux got it right with MADV_DONTDUMP

quotemstr• 7 years ago

All memory is mmaped, especially on OpenBSD, which deprecated basically-mmap-with-a-mustache brk. There's no such thing as "regular old virtual memory".

davidcuddeback• 7 years ago

There’s also malloc_conceal() and calloc_conceal(), as discussed in the article.

joosters• 7 years ago

Why don’t they just default to not writing core dumps, and forcing the sysadmin to explicitly enable them when debugging an app?

This setup seems like the worst of both worlds. Core dumps get written but now probably lack the information critical to debugging, making them worthless.

OpenBSD Recent Security Innovations

Related Stories