[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 Mar 2013 01:46:49 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Mathias Krause <minipli@...glemail.com>,
Solar Designer <solar@...nwall.com>
Subject: Re: CVE Requests (maybe): Linux kernel: various info
leaks, some NULL ptr derefs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/05/2013 01:52 PM, Mathias Krause wrote:
> Hi Kurt,
>
> I don't care much about info leaks beyond merely fixing them. But
> Alexander asked me to request a CVE ID for the recent crypto fix
> of mine and as I did quite a few of such fixes in the recent past,
> I'll just list them all here. The information might be a bit scarce
> for a CVE ID request but as I don't expect any CVE IDs anyway, I
> didn't wanted to do too much unnecessary work. ;)
CVE ID's prompt people to back port these security fixes which is a
good thing indeed =).
> 9a5467b crypto: user - fix info leaks in report API
>
> This is quite a big info leak of heap, stack and .text memory. No
> crypto material, though. Also, as the crypto user API is protected
> by capable(CAP_NET_ADMIN), it's not as critical as is might sound
> on the first sight. It affects all versions from the introduction
> of the crypto user API -- that is v3.2 - v3.8.
>
>
> Older info leak fixes follow. All of them ended up in v3.6 and
> were backported to the stable/longterm kernels at the time:
>
> ecd7918 xfrm_user: ensure user supplied esn replay window is valid
> What: Leaks up to ~3.5kb heap memory. Was protected by
> capable(CAP_NET_ADMIN) at the time.
>
> 1f86840 xfrm_user: fix info leak in copy_to_user_tmpl() What: Minor
> leak of stack memory. Was protected by capable(CAP_NET_ADMIN) at
> the time.
>
> 7b78983 xfrm_user: fix info leak in copy_to_user_policy() What:
> Minor leak of heap memory. Was protected by capable(CAP_NET_ADMIN)
> at the time.
>
> f778a63 xfrm_user: fix info leak in copy_to_user_state() What:
> Minor leak of heap memory. Was protected by capable(CAP_NET_ADMIN)
> at the time.
>
> 4c87308 xfrm_user: fix info leak in copy_to_user_auth() What: Leak
> of heap memory. Was protected by capable(CAP_NET_ADMIN) at the
> time.
>
> 43da5f2 net: fix info leak in compat dev_ifconf() What: Minor leak
> of stack memory.
>
> 2d8a041 ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
> What: Minor leak of stack memory.
>
> 7b07f8e dccp: fix info leak via
> getsockopt(DCCP_SOCKOPT_CCID_TX_INFO) What: Minor leak of stack
> memory.
>
> 3592aae llc: fix info leak via getsockname() What: Major leak of
> stack memory (up to 128 bytes).
>
> 04d4fbc l2tp: fix info leak via getsockname() What: Minor leak of
> stack memory.
>
> 792039c Bluetooth: L2CAP - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> 9344a97 Bluetooth: RFCOMM - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> f9432c5 Bluetooth: RFCOMM - Fix info leak in
> ioctl(RFCOMMGETDEVLIST) What: Minor leak of heap memory.
>
> 9ad2de4 Bluetooth: RFCOMM - Fix info leak in
> getsockopt(BT_SECURITY) What: Minor leak of stack memory.
>
> 3f68ba0 Bluetooth: HCI - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> e15ca9a Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
> What: Minor leak of stack memory.
>
> 3c0c5cf atm: fix info leak via getsockname() What: Minor leak of
> stack memory.
>
> e862f1a atm: fix info leak in getsockopt(SO_ATMPVC) What: Minor
> leak of stack memory.
>
> a117dac net/tun: fix ioctl() based info leaks What: Leak of 36
> bytes of stack memory.
>
> 0143fc5 udf: avoid info leak on export What: Minor leak of heap
> memory.
>
> fe685aa isofs: avoid info leak on export What: Minor leak of heap
> memory.
can you provide the full git id/link to these? Also were they all
discovered by the same researcher?
> Now do follow a few NULL ptr derefs ending up in privilege
> escalation if a user is able to map page 0 or probably a DoS
> otherwise. Also those have all been fixed in v3.6 and backported to
> the corresponding stable/longterm kernels at the time:
>
> 864745d xfrm_user: return error pointer instead of NULL What: Wrong
> return of NULL leads to wrong path in calling function leading to
> NULL pointer deref of skb.
>
> 276bdb8 dccp: check ccid before dereferencing What: Missing NULL
> pointer check leads to NULL function pointer.
can you provide the full git id/link to these? Also were they all
discovered by the same researcher?
> That's all. Enough, I guess ;)
>
>
> While we are at it: Do we care about getting CVE IDs for info
> leaks? If so, all of them or only for the ones with leaks above a
> certain threshold (>= 16 bytes, e.g.)?
Yes please. Much like DNA fragments you can potentially string them
together to reveal larger things.
> Regards, Mathias
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJRNwJ5AAoJEBYNRVNeJnmTVtYQAMSwhmnF4hScjVRMmJuc/mcM
ExgC7R1khhxIG5rPU+ZwVvLnfO0hby2oRIIkFf/2Aaj4mMXe5iBLzO3xdgWS1Ekv
M4PE57f8X+4G+9PaYWW1ebWDuf1HAVc8fxneZ1aBC3xPEg+VEgutow8To4x5rwyp
Y0iO4OsMU6nHLj2dDodKXlIvzoSm7Vdrgx+GE96fAQTxHgsamyKBP/cDzl7QwowZ
dXZEJ1pK6H2pMVbutKLYQmUMhXRCtNajZaqRbysvoLrnjcY0G56Gf+pZUWPWaOqf
K2g81VcoG4buc1zoDCAcmUBHSM69g3gN2Rz+Wvqx1G9ABQyIaSpuyaP4cLLHTtPn
AS4pql+TJMyvP+yWDSM3a8RGRaO+9jzdJCrXVDrq5mdEmjkqgAT7R3XOvLTouJp8
0QnGAYczKf09PeRuaficD8eg5GUGYbrIvVp00qG9wBcPhvVNNTJrsi/rjbiroW/g
KDQzlKqxKbixaxj4tFtGpyeDXcKR1weT9JLG21IZmMA3NLhGuvUbSPpdL3Yqbshh
jGtxy0QIcLGl3j+mYwsgXYt26oCg80tFrYXKoyBlD/D+7NjUDOfPReauB6nlsAiU
+KWO70sxeIjbRGqmJD1/scIzzBVZKPJ/rdM5Y2A+dhioVg7vAG1RxyxHY+nHMpGt
wX0XTKmw9WnfdDe4U0T/
=ldnf
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
