netdev - Re: [PATCH] Prevent reading uninitialized memory with socketfilters

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-next>] [day] [month] [year] [list]

Message-ID: <1695276347-1289413089-cardhu_decombobulator_blackberry.rim.net-434693855-@bda083.bisx.prod.on.blackberry>
Date:	Wed, 10 Nov 2010 18:18:08 +0000
From:	"Dan Rosenberg" <drosenberg@...curity.com>
To:	"David Miller" <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, stable@...nel.org, security@...nel.org
Subject: Re: [PATCH] Prevent reading uninitialized memory with socketfilters

The code sample I linked to clearly demonstrates exactly how to accomplish this, if you had bothered to read it.  I install a socket filter that loads the desired uninitialized int into the accumulator, performs some bit shifting to get the desired byte, and returns the accumulator.  Since the packet size is greater than 256, the packet will be truncated based on the value of that byte, allowing me to determine its value.

There are no restrictions - I can access any byte in the array regardless of its value.

-Dan

------Original Message------
From: David Miller
To: drosenberg@...curity.com
Cc: netdev@...r.kernel.org
Cc: stable@...nel.org
Cc: security@...nel.org
Subject: Re: [PATCH] Prevent reading uninitialized memory with socketfilters
Sent: Nov 10, 2010 1:07 PM

From: Dan Rosenberg <drosenberg@...curity.com>
Date: Wed, 10 Nov 2010 06:12:47 -0500

> 
>> 
>> Prove it.
> 
> I hope this was a joke.

It absolutely is not.

You are very much not the first person ever to try and add an
expensive memset() here.

So the onus is really on you to prove this assertion and show the
exact code path by which the user can actually see any uninitialized
kernel stack memory (he can't, he can peek at certain values in a
certain extremely contrived range, making the leak useless), rather
than point us at some web external site archive of a list posting
which we cannot easily quote and reply to here.

I think you cannot do it, really.  Except in the AF_PACKET case, the
sockets can only see "0" or a negative error code, not the actual
sk_run_filter() return value.

In the one exception, AF_PACKET, the range of values the user can
see are in the range of MTU of the device being accessed, which
realistically is 1500 bytes.  This means the user cannot see any
kernel stack value outside of the range 0 to 1500, which isn't
worth using this expensive memset to guard against at all.

I don't even think it's worth adding all of the extra cpu cycles
incurred by Eric Dumazet's scheme of using a bitmap test on every
single memory buffer access.