embedded dropbear...

Matt Johnston matt at ucc.asn.au
Tue Apr 16 23:44:00 WST 2013


Hi,

I'm pretty sure there'd be interest in such a port, even if
there are no immediate takers. I guess it depends how much
effort you want to put in - a separate tarball (or hg
branch ease of merging future versions) might be enough for other
people to get going. It doesn't sound like the changes would
be _too_ intrusive, so could probably live in the main tree.
One concern would be avoiding it breaking from other changes
- would it be easy enough to build the embedded variant
targetting a normal Linux-type platform?

A few comments inline below.

>   no fork(), no exec(), no pipes, etc..  This includes no use of
> fprintf(...) as well.

Missing fprintf() might make the code a bit messier - did
you encounter other uses than for logging/error messages?

> - I loosely base this on the "no-inetd" option; and I
> heavily chopped away at things in options.h (hopefully
> without breaking anything).
> - Since there is no shell, this simply hooks to an internal command
> line processor.
> - Currently the server is built to run as if the following command
> line were invoked:
>   ./dropbear -s -F -b "yada yada" -r dropbear_rsa_host_key
>   and since I do have an FS, I created the dropbear_rsa_host_key
> file using dropbearkey on my host machine, and simply
> copied it to my embedded system's FS for now.  The need
> for the FS could easily be eliminated.

A good source of random values is pretty important for
SSH security. If there are say 16 bytes of good random
values written at "manufacturing", that could be read in as
input then saved out at Dropbear startup and occassionally
during operation (reusing the same seed twice would be very
bad). The write_urandom() would work for writing a value
back. A flash write per boot isn't great, but hard to see a
better way without random number generation hardware.

> DETAILS:
> My build puts the two math directories into a library, and
> then builds the server using portions of ~25 of the ~65 .c
> files that are in the main dropbear directory.

Did you have to change much in the libtom libraries? I'm
planning to merge in tomsfastmath support (using the ltc_mp
descriptor to keep libtommath working as a fallback), that
might help performance as well by reducing malloc()s.

> I simulate interaction with a shell by intercepting incoming
> characters in common_recv_msg_channel_data().  Each line
> of text is simply passed to a command line parser.  While
> that command line is being processed, all output from that
> embedded command is sent through the function
> ssh_putchar():
> 
> static void
> ssh_putcharc(struct Channel *channel,char c)
> {
>     CHECKCLEARTOWRITE();
>     buf_putbyte(ses.writepayload, SSH_MSG_CHANNEL_DATA);
>     buf_putint(ses.writepayload, channel->remotechan);
>     buf_putint(ses.writepayload, 1);
>     buf_putbyte(ses.writepayload, c);
>     encrypt_packet();
> }

You may as well write out at least 12 bytes at once (I
think), since encrypt_packet pads out to MIN_PACKET_LEN (=16) 
with at least 4 bytes of padding.

> and one other important thing...
> At the bottom of encrypt_packet(), I call write_packet() so that the data
> is immediately pushed out the socket.

That sounds fine.

> SUMMARY:
> Thats about it in the nutshell.  The two big gotchas with this were
> issues that
> would not necessarily be important in a process-based environment:
> 
> 1. The use of dropbear_exit() for errors requires the use of
> setjmp/longjmp because
>    its in a thread that needs to cleanup properly.
> 2. The heap is clean when exits are clean; but things get messy in a lot of
>    exception cases; hence, the need for a dropbear-specific heap which
>    allows me to force a clean heap when the session ends (simulating
> the cleanup that
>    is automatically done when the process exits).

It'd need a close look over releasing any resources other
than memory allocations, though there probably aren't many
things. libtom* might make use of some static variables.
Dropbear has a small number that can be fixed.

Cheers,
Matt


More information about the Dropbear mailing list