Hacker News Reader

Comment by tedunangst | Hacker News Reader

If you infiltrate a system and see sshd.core in the filesystem, you're not going to snarf that up?

I just checked the source and openssh doesn't appear to set madvise(MADV_DONTDUMP) anywhere :-( That seems like an oversight? For comparison openssl has a set of "secure malloc" functions (for keys etc) which uses MADV_DONTDUMP amongst other mitigations.

Interestingly, it looks like ssh-agent disables core dumps[1], but I don't see similar usage for sshd

1: https://github.com/openssh/openssh-portable/blob/694150ad927...

sshd runs as root, so the core dumps would be readable as root-only, no? If you have root access already you could dump it even while it's still running with ptrace anyways

>sshd runs as root, so the core dumps would be readable as root-only, no

Yes, although the article we're discussing shows that you can't rely on that, the dump could be subsequently moved to a developer machine for investigation, and unencrypted key material left in could be compromised that way... defense in depth would make sense here.

On OpenBSD, you'd be looking for MAP_CONCEAL, though it's not used in many places, either.

Secret materials for ssh keys won’t be in sshd. They stay client side. Granted m, host keys could be compromised, so you could impersonate a server, but a sshd key leak won’t give direct access

It could leak passwords, though, unless you’re very certain your overwriting after validation always works.

Yes, though it does have the host key which you could use to do a MITM attack.

MADV_DONTDUMP or MAP_CONCEAL don't appear anywhere in the source, client or server (with the exception of the seccomp filter where they're just used to filter potential system calls).

Key material aside, such a coredump could give some hints towards someone else’s capabilities, and point you in an interesting direction for finding new and exciting ways to own more shit.

Reply on news.ycombinator.com