User: Password:
|
|
Subscribe / Log in / New account

Kernel.org's road to recovery

Kernel.org's road to recovery

Posted Oct 6, 2011 22:21 UTC (Thu) by nix (subscriber, #2304)
In reply to: Kernel.org's road to recovery by PaXTeam
Parent article: Kernel.org's road to recovery

for extra bones, explain the security risk of commit 976d167615b64e14bc1491ca51d424e2ba9a5e84.
You need to generate a rather contrived scenario for that one, but it is possible. e.g. shortly before that commit, 805e969f6151eda7bc1a57e9c737054230acc3cc was committed, which as it can cause a network interface to go dead could constitute a form of DoS attack. Userspace software could consult the kernel version and arrange to reduce its network traffic output if a buggy kernel was in use. Thus, skipping this commit would reduce the traffic on that network interface. More importantly, if some *future* commit fixed a security hole -- say, if you were talking about commit a102a9ece5489e1718cd7543aa079082450ac3a2, since we can't foretell the future -- then if that commit was skipped, software which checked the kernel version and refused to do something that would trigger a known hole would be misled into triggering the hole by the absence of that commit.

But, yes, this is quite contrived, and any software which checks for workarounds for security holes in -rc kernels by version number checking would rapidly become unmaintainable. I hope.


(Log in to post comments)

Kernel.org's road to recovery

Posted Oct 7, 2011 7:50 UTC (Fri) by PaXTeam (guest, #24616) [Link]

right, and if sofrware checked the phase of the moon then you'd blame the moon, not the software. great thinking there, as usual.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds