About Archive Tags RSS Feed


So about that idea of using ssh-keygen on untrusted input?

12 October 2015 21:50

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 [email protected] 
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 ;)



Comments on this entry

icon Marek at 12:49 on 12 October 2015

Now, what happens if your crashers are in authorized_keys...? ;-)

icon Steve Kemp at 13:04 on 12 October 2015

Sadly nothing useful - sshd doesn't die, for example.

icon Marek at 13:51 on 12 October 2015

Interesting that the project is using different code paths (or even different code?) to parse a key in ssh-keygen and to read authorized_keys... I wonder why that is.