My previous blog post related to using ssh-keygen to generate fingerprints from SSH public keys.
At the back of my mind was the fear that running the command against untrusted, user-supplied, keys might be a bad plan. So I figured I'd do some fuzzing to reassure myself.
The most excellent LWN recently published a piece on Fuzzing with american fuzzy lop, so with that to guide me I generated a pair of SSH public keys, and set to work.
Two days later I found an SSH public key that would make ssh-keygen segfault, and equally the SSH client (same parser), so that was a shock.
The good news is that my Perl module to fingerprint keys is used like so:
my $helper = SSHKey::Fingerprint->new( key => "ssh ...." );
if ( $helper->valid() ) {
my $fingerprint = $helper->fingerprint();
...
}
The validity-test catches my bogus key, so in my personal use-cases this OK. That said it's a surprise to see this:
skx@shelob ~ $ ssh -i key.trigger.pub steve@ssh.steve.org.uk Segmentation fault
Similarly running "ssh-keygen -l -f ~/key.trigger.pub" results in an identical segfault.
In practice this is a low risk issue, hence mentioning it, and filing the bug-report publicly, even if code execution is possible. Because in practice how many times do people fingerprint keys from unknown sources? Except for things like githubs key management page?
Some people probably do it, but I assume they do it infrequently and only after some minimal checking.
Anyway we'll say this is my my first security issue of 2015, we'll call it #roadhouse, and we'll get right on trademarking the term, designing the logo, and selling out for all the filthy filthy lucre ;)
Tags: afl, security, ssh 3 comments