lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20100110235017.GA8959@electric-eye.fr.zoreil.com> Date: Mon, 11 Jan 2010 00:50:17 +0100 From: Francois Romieu <romieu@...zoreil.com> To: Ben Hutchings <ben@...adent.org.uk> Cc: David Miller <davem@...emloft.net>, eric.dumazet@...il.com, nhorman@...driver.com, netdev@...r.kernel.org Subject: Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3) On Sun, Jan 10, 2010 at 01:57:18AM +0000, Ben Hutchings wrote: > On Fri, 2010-01-08 at 16:02 -0800, David Miller wrote: > [...] > > Whilst the above will end up gobbling up to (16K - BIG_PACKET_SZ) > > worth of innocent frames, the DMA engine seems to keep things at least > > self-consistent. > > > > The only bug seems to be the omission of the LastFrag trigger at the > > proper place. > > No, the attacker controls the completion status by writing it in > previous valid frames. Please read the slides > (<http://events.ccc.de/congress/2009/Fahrplan/attachments/1483_26c3_ipv4_fuckups.pdf> pages 80-87). Yes. The paper suggests that it should be possible to control opts1 either completely or enough to break things badly. The first packet does not hurt too much. Things look different in the descriptor of the subsequent packets. I am more or less able to control bits 8-23 from 0-31 in opts1, enough to be unpleasant. Iff the FirstFrag and LastFrag bits can not be set on these packets, it should be enough to (1) do the fragmented_frame test sooner and return the descriptor to the chipset. Otherwise we can (2) take a complete reset on the first suspect packet (whose pattern is more specific) to stop the challenger here. FWIW, a netratelimited printk of the source mac address may help too. I am biased in favor of (2) as: - it will not inhibit multi-desc packets - the challenger is supposed to be in the LAN and can already hurt quite a lot anyway Comments ? -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists