Wandering Thoughts archives

A surprise with switching to holding keys in ssh-agent

Every so often I want to transfer a root-only file from my office workstation off to another machine for analysis or the like (the reasons this is necessary are complex). So every so often I wind up doing this:

$ /bin/su
# scp /some/file cks@server:/tmp/foobar
cks@server's password: [...]

Except that I lied there. That password prompt is certainly what used to happen and it's what happens when I do this same operation from any of our servers, but on my office workstation the scp just works without any password challenge. The first time that this happened I was surprised for a bit, then I worked out what was happening.

What's happened is that I switched to holding my SSH keys in ssh-agent instead of having them sitting in $HOME/.ssh. Su'ing to root does not clear the environment variables that tell commands how to talk to my ssh-agent process and of course root has the permissions necessary to access the SSH agent authentication socket, so the root-run scp sees that it has a SSH agent available and uses it. Voila, passwordless access for root to my remote account. This doesn't happen on our servers because I don't forward my SSH agent to my account on our servers (I consider it too dangerous).

Of course root had just as much access to my keys back in the days of having them sitting unencrypted in $HOME/.ssh. The difference is that su'ing to root changes $HOME, so scp, ssh, and so on didn't look at ~cks/.ssh et al, they looked at ~root/.ssh and the latter didn't have my keys (or the SSH configuration that would have told SSH how to use the keys). It's the combination of using a SSH agent and su passing through the environment variables that make SSH programs to talk to it that leads to this particular result.

Also, this is specific to habitually using su instead of sudo. By default, sudo preserves only a relatively few environment variables and removes everything else, and the SSH agent environment variables aren't among the environment variables that make it through. Su is from an older era and so generally defaults to preserving almost everything (for good or bad, take your pick).

(Since sudo passes through things like $XAUTHORITY and $DISPLAY, arguably it should also pass through the SSH agent environment variables. But it doesn't now and I expect that it's unlikely to ever change the default; regardless of any merits of a change, there are too many arguments that anti-change people could muster here.)

My view on spam and potential denial of service attacks on anti-spam systems

In a comment on yesterday's entry on a shift in malware packaging, Jinks asked a very good question:

Since you're working with inspecting zip files, how does your setup handle denial of service attacks against the unzipping part?

Like, let's say I sent you a zipped 30TB sparse file. Or a neverending zip quine.

I've found that many commercial solutions can easily choke on maliciously crafted zip files. Do you have any special provisions in your scripts to prevent these attacks?

The straightforward answer is that we're protected against ZIP quine attacks by having very simple code that only goes one level deep in nested ZIP archives, in large part because Python's zipfile module makes this the relatively natural way to write this code. We're semi-protected against ballooning ZIP archives because we only try to expand .zip files.

But this is a copout. The real answer is that I haven't bothered to write the code to defend against such denial of service attacks, in large part because we don't need it now and I don't expect to ever need it in the future. If I was writing code that would defend a large, prominent organization like Google or Hotmail or something, I would say that I absolutely had to engineer in DOS protection from the start because sooner or later some joker would try sending us one just to see what would happen. But deliberate, focused DOSs against my particular little section of the Internet are unlikely (and if they happen we have plenty of softer targets lying around than the mail system; sometimes such DOSes even happens naturally).

But what about spam, malware, and ransomware, you may ask? Surely they may DOS us this way at some point. My view is that if they do, it will be by accident. If you think about it, spam in general has an extremely good motive to avoid DOS'ing people's email systems. To wit, a DOS'd email system is one that is not letting the spam, malware, or ransomware through (it's not letting anything else through either, but the spammer doesn't care about who else is being affected). If a spammer finds some sort of mail that makes a popular anti-spam system choke, I expect them to carefully avoid it for the same overall reason that they avoid sending things that are easily scored as spam.

In other words, what's valuable to a spammer isn't email that causes a DOS, it's email that bypasses filtering systems somehow. It's possible that such email will DOS our systems, but right now I rate that as relatively unlikely; the stuff that would give my filtering system heartburn are mostly things that would probably lock up an anti-spam system instead of bypass it.

(Maybe I will add an inner-zip length restriction, though. It's probably not hard, and there's good reason to skip trying to check out an inner zip that's too large.)

PS: I suspect that commercial solutions are often not robust against these things for the same reason my code isn't; namely, it's just not something that comes up in the wild. Arguably they should do better, since they're general purpose commercial software.