6 ms·
What circumstances are needed for this to be exploitable? Wondering if iptables could mitigate for systems where upgrading the kernel is non-trivial.
by mkj 10y ago
What circumstances are needed for this to be exploitable? Wondering if iptables could mitigate for systems where upgrading the kernel is non-trivial.
- zzzcpan 10y agoHaven't looked at this too closely, but iptables are unlikely to help. The bug appears to be in the recvmmsg() syscall, which is where the packet leaves the kernel and enters the userspace. The syscall itself is not that widely used, only for some unusually optimized UDP servers, you are unlikely to have one running. But you can check with strace just to be sure.
- mkj 10y agoYep. Though I assume this needs some interesting network traffic to trigger it.
- caf 10y agohttps://codesearch.debian.net/search?q=[^_]recvmmsg\%28[^\%29]&perpkg=1&page=1 https://codesearch.debian.net/search?q=[^_]recvmmsg\%28[^\%2... (Many of the results are for code like language runtimes and debugging tools that don't actually use recvmmsg() themselves)
- ajb 10y agoOuch, it's in chromium though.
- startling 10y agoI wrote a bit about it: https://blog.lizzie.io/notes-about-cve-2016-7117.html https://blog.lizzie.io/notes-about-cve-2016-7117.html tl;dr looks like it'd function well a local privilege exploit. not an expert, but as a remote exploit think it would need 1) a service running recvmmsg (which is kind of unlikely) 2) a way to cause recvmsg to error, and 3) a way to cause the service to close its socket in the middle of the recvmmsg call.
- vzcx 10y agoNice writeup! I was just starting to look into this since people were claiming it was pretty severe and yet I hadn't seen any POC's. Have you made any more progress? For whatever my opinion is worth (i.e. not much), I would agree with you that remote exploitation of this particular bug would be really difficult.