From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bb0uZ-0001We-OB for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:42:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bb0uY-0001Vp-VV for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:42:51 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bb0uY-0001Vi-SN for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:42:50 -0400 Received: from [213.146.130.142] (helo=trantor.org.uk) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Bb0tS-0002SR-2D for qemu-devel@nongnu.org; Thu, 17 Jun 2004 13:41:42 -0400 Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning From: Gianni Tedesco In-Reply-To: <20040617160526.GA20148@sentinelchicken.org> References: <20040617043838.GA1938@sentinelchicken.org> <1087484840.21569.108.camel@sherbert> <20040617160526.GA20148@sentinelchicken.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ur5VndllOQJrX3P65+rF" Date: Thu, 17 Jun 2004 18:41:25 +0100 Message-Id: <1087494085.3375.133.camel@sherbert> Mime-Version: 1.0 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 --=-Ur5VndllOQJrX3P65+rF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-06-17 at 09:05 -0700, Tim wrote: > > Thats only worrisome from a security perspective if qemu was designed t= o > > run SUID, which I doubt that it is... Of course it's a bug and needs > > fixing though. >=20 > 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... cool :) > > 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. >=20 > Agreed. The slirp code in particular worries me in this respect. I'll stick it on my todo list to have a look around in there when i'm bored. > > 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 easil= y > > check if input was truncated, in some cases, silent truncation could be > > a bug. >=20 > 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. nooooope, strcpy has no way of knowing how big the buffer is other than what you tell it. It's likely that all (or most) of the buffers that are strcpy'd to are initialised to zero / .bss so it doesn't matter in reality, but better safe than sorry. What if some buffer is moved to stack later, that would expose the latent bug. --=20 // 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 --=-Ur5VndllOQJrX3P65+rF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA0dfEkbV2aYZGvn0RAh79AJ9SusqNUFQzyYKXMw8svUdhEK+eiQCffrEE 0SRUoXSco5d5XY+pASgv/Co= =JcYT -----END PGP SIGNATURE----- --=-Ur5VndllOQJrX3P65+rF--