From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BazOo-0005Ma-F6 for qemu-devel@nongnu.org; Thu, 17 Jun 2004 12:05:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BazOk-0005KA-Nf for qemu-devel@nongnu.org; Thu, 17 Jun 2004 12:05:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BazOk-0005K5-JK for qemu-devel@nongnu.org; Thu, 17 Jun 2004 12:05:54 -0400 Received: from [206.72.67.39] (helo=claudius.sentinelchicken.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1BazNO-0007uv-UP for qemu-devel@nongnu.org; Thu, 17 Jun 2004 12:04:31 -0400 Date: Thu, 17 Jun 2004 09:05:27 -0700 From: Tim Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning Message-ID: <20040617160526.GA20148@sentinelchicken.org> References: <20040617043838.GA1938@sentinelchicken.org> <1087484840.21569.108.camel@sherbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087484840.21569.108.camel@sherbert> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > 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