> In fact, the article's conclusion that the OpenSSH team should have
> rolled their own memory management code rather than use tried,
> tested and approved libraries
That's not the conclusion I draw from the article.
I rather read it as warning that even innocent and quite common
operations like realloc() or using buffered I/O can have security
implications, so one need to be extra extra extra careful when
writing code that handles sensitive data. In other words, security can
be even harder than security professionals think.
I agree with you. And while I don't think there's any secure way to use realloc(), I would like to remind people that stdio does give you control over the internal buffer (setvbuf()), which you can potentially set to a buffer that can't get swapped to disk and which you can zero out at the appropriate time. You can also call fflush() to be sure that the data in stdio's buffer can be zeroed even before the file is closed.
One alternative would be to sidestep this memory-reallocation-and-buffering problem altogether and just use the code that already exists to connect to an ssh-agent, even when only private keys from the local filesystem are used for authentication:
Let ssh spawn an ephemeral ssh-agent just for the duration of the key-exchange and just for this single ssh instance. Kill it once authentication is complete.
That's not the conclusion I draw from the article.
I rather read it as warning that even innocent and quite common operations like realloc() or using buffered I/O can have security implications, so one need to be extra extra extra careful when writing code that handles sensitive data. In other words, security can be even harder than security professionals think.