netdev - Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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