Bug 1622404 (CVE-2018-10938) - CVE-2018-10938 kernel: infinite loop in net/ipv4/cipso_ipv4.c:cipso_v4_optptr() allows for DoS
Summary: CVE-2018-10938 kernel: infinite loop in net/ipv4/cipso_ipv4.c:cipso_v4_optptr...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2018-10938
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1619536
TreeView+ depends on / blocked
 
Reported: 2018-08-27 05:07 UTC by Sam Fowler
Modified: 2019-09-29 14:57 UTC (History)
48 users (show)

Fixed In Version: kernel 4.13-rc5
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipso_v4_optptr() function in net/ipv4/cipso_ipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.
Clone Of:
Environment:
Last Closed: 2018-08-27 11:45:59 UTC


Attachments (Terms of Use)

Description Sam Fowler 2018-08-27 05:07:19 UTC
A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipso_v4_optptr() function in net/ipv4/cipso_ipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.

References:

http://seclists.org/oss-sec/2018/q3/179

Introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04f81f0154e4bf002be6f4d85668ce1257efa4d9

Fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40413955ee265a5e42f710940ec78f5450d49149

Comment 3 Vladis Dronov 2018-08-27 11:45:59 UTC
Notes:

None of the Red Hat's products are vulnerable to this flaw.

Comment 4 hayg 2018-08-28 23:23:16 UTC
I'd like to point out that this attack is very difficult to execute over the WAN since packets with IPv4 options are often dropped by routers. 

From https://tools.ietf.org/html/rfc7126#section-1:
   We note that data seems to indicate that there is a current
   widespread practice of blocking IPv4 optioned packets.

I was unable to deliver an innocuous IP packet with IP options to both my Digital Ocean and AWS virtual private servers.

Comment 5 hayg 2018-08-28 23:23:42 UTC
I'd like to point out that this attack is very difficult to execute over the WAN since packets with IPv4 options are often dropped by routers. 

From https://tools.ietf.org/html/rfc7126#section-1:
   We note that data seems to indicate that there is a current
   widespread practice of blocking IPv4 optioned packets.

I was unable to deliver an innocuous IP packet with IP options to both my Digital Ocean and AWS virtual private servers.

Comment 6 hayg 2018-08-29 00:51:29 UTC
Also, *why* is Red Hat not bulnerable?

Comment 7 Vladis Dronov 2018-08-29 13:16:58 UTC
(In reply to hayg from comment #4)
> I'd like to point out that this attack is very difficult to execute over the
> WAN since packets with IPv4 options are often dropped by routers. 

Thank you for pointing this out. Let me add, though, that nevertheless the flaw still exists and can be exploited in other environments.

> Also, *why* is Red Hat not bulnerable?

This is so as the code with the flaw is not present in the Red Hat's products: https://access.redhat.com/labs/psb/

Comment 8 hayg 2018-08-29 17:42:01 UTC
Thank you Vladis. I am rather upset by the reporting around this flaw. As far as I can tell this only affects SELinux enabled kernels which have a CIPSO rule added. Can you confirm whether that's the case? It is a huge deal that this is only an issue in the non-default configuration, and a rather niche one at that. I can tell you that I've already wasted 10s of hours on this because of the lack of detail which made it seem sensational.

Comment 9 Vladis Dronov 2018-08-30 17:46:16 UTC
(In reply to hayg from comment #8)

Thank you for the update. 

> this only affects SELinux enabled kernels which have a
> CIPSO rule added. Can you confirm whether that's the case?

it is not only selinux but also SMACK.

could you, please, share the results of your research?

Comment 10 hayg 2018-08-30 18:39:21 UTC
(In reply to Vladis Dronov from comment #9)
Thank you for confirming. This puts me at ease.

> could you, please, share the results of your research?
Pretty much what you just stated, that it affects only selinux and SMACK and only if you have a CIPSO rule enabled. This shrinks the affected audience to a much much smaller number of machines. Adding to this the fact that these packets will only be routed over the LAN (if that) and not the WAN, this does not even affect my org. 

Thanks,
Hayg

Comment 11 Vladis Dronov 2018-08-31 13:09:09 UTC
(In reply to hayg from comment #10)
> it affects only selinux and SMACK and only if you have a CIPSO rule enabled.

I've updated the flaw's description to make it clear, thank you.

Comment 12 hayg 2018-08-31 21:19:03 UTC
Awesome, thanks Vladis! I hope this saves some folks time.


Note You need to log in before you can comment on or make changes to this bug.