qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Security house-cleaning


From: Tim
Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning
Date: Thu, 17 Jun 2004 09:05:27 -0700
User-agent: Mutt/1.5.5.1+cvs20040105i

> 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.

Yes, I agree on both points.  There is little I can offer to this
project right now, besides testing, and general code cleanup.  I know
almost nothing about hardware emulation, so just trying to help out with
what I know...

> 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.

Agreed.  The slirp code in particular worries me in this respect.

> 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.

Ahh, good point.  However, if you specify a size one less than the size
of your buffer, I believe strncpy fills the rest of your buffer w/
nulls, doesn't it?  Or is that OS-specific?  So far, I have been keeping
my size in strncpy() one less than the buffer size (see the 256->255
change on one particular buffer, or instance).  However, this method is
prone to off-by-one bugs, so I might switch to snprintf() in some cases,
as you suggest.

> 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 :)

Sure thing, I'll do that next time.

Thanks for the input!
tim






reply via email to

[Prev in Thread] Current Thread [Next in Thread]