A surprise with switching to holding keys in
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
just works without any password challenge. The first time that this
happened I was surprised for a bit, then I worked out what was
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
process and of course root has the permissions necessary to access
the SSH agent authentication socket, so the root-run
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
ssh, and so on
didn't look at
~cks/.ssh et al, they looked at
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
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
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
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.