On Wed, 2004-06-16 at 21:38 -0700, Tim wrote:
> I have to say, the core QEMU code is quite clean, and I feel that much
> more confident in using it for honeypot projects later on. ;-)  The
> biggest culprit in terms of potential overflows, was the slirp code.
> There were some disturbing instances where strings were being pulled
> directly from the command line and tossed into a fixed-length buffer
> with no checks. =-X  I can't say that I understand at all how slirp
> works, so I don't know if it is exploitable.

Thats only worrisome from a security perspective if qemu was designed to
run SUID, which I doubt that it is... Of course it's a bug and needs
fixing though.

What would be more worrying is if there were overflows in the packet
processing allowing (possibly compromised) guest OS or remote machines
to take over qemu process by sending an exploit in a malformed packet.

The other possible vector I can think of is if there are exploits in
specific devices where you have things like audio processing going on
etc... Also when USB support exists, it could be possible to send
packets containing an overflow that could trip up a driver and execute
code, so that will need careful attention too.

Anyway, it's nice to see someone cares and is looking at the security of
qemu ;)

A quick note on the patch: where you are replacing strcpy() with
strncpy(), you are better to use snprintf(buf, sizeof(buf), "%s",
input); as that guarantees nul termination. It also allows you to easily
check if input was truncated, in some cases, silent truncation could be
a bug.

PS. Could you send README and patch as 2 attachments next time, dealing
with attachments, and archives is a PITA when u just want to skim a
patch :)

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D