61–70 of 121 posts
Earlier quoted context omitted.
Since when did the term "responsible disclosure" mean allowing the vendor unlimited time to fix it?
If it's not unlimited, what's the limit? Apparently a month isn't long enough.
To all the kernel programmers out there, can we get a HN-level ELI5 for this? It looks like a total system compromise is possible. Under what conditions? Any ways to ensure we don't get pwned?
I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action - user space would ask for something it is permitted to do at first, kernel would read it and proceed to perform access check. User space meanwhile writes something different to the original memory area that specified the action - this time something privileged - kernel comes back successfully performing the access check for the older action and now executes the privileged action from the overwrite.
j00ru/project zero used modified Bochs (BochsPWN) to detect double memory fetch patterns to find similar vulnerabilities in the Windows kernel.
Earlier quoted context omitted.
"Responsible Disclosure" is an Orwellian term concocted by vendors to control the actions of independent vulnerability researchers who work without real compensation, using information freely available to consumers, in competition with malicious attackers. The term you're looking for is "Coordinated Disclosure". Yes, Coordinated Disclosure would involve sending the bug to Apple and waiting for them to publish it. If…
You're correct, but I think it's worth going into a bit more detail about some of the tradeoffs involved in the concept of "Responsibility" as it applies to security research and exploit discovery, because there are a few clashing objectives that shape what the right choice is each time if we're considering how to minimize harm to all parties (if someone just wants to sell it to the highest bidder none of this applie…
I myself have found myself in total agreement in one instance, and then a week or two later a big exploit comes out that makes me really wish some patches had made it out first.
What I think it comes down to is that any vendor needs to assume the exploit can come out any minute after notification, and act accordingly (if it's important, they better damn well get it patched quick). Any researcher should assume that if they act like an asshole and aren't accommodating in some way, they'll get raked over the coals by at least some of the technical public. As tptacek noted, coordination is best, and that requires a dialogue.
Also worth noting is that sometimes there is no patch. Some security problems are of the degree that the entire process is fundamentally flawed, and in those cases there's little to be gained waiting for the vendor, unless the vendor is working to notify all clients and recommend they cease use of the affected service or product. If, for example, you identify a flaw in in how a protocol is defined, and almost all implementations are flawed, the only responsible thing to do might be to publish publicly. Otherwise you're just favoring some groups over others in some way or another.
Earlier quoted context omitted.
Needs to be running on the host already (nothing remote), achieves full system compromise by itself, but logs you out in the process. Can wait for logout though and is fast enough to run on shutdown/reboot until 10.13.1. On 10.13.2 it takes a fair bit longer (maybe half a minute) after logging out, so if your OS logs you out unexpectedly... maybe pull the plug? And maybe don't download & run untrusted software until…
> Also, any decent antivirus shouldn't take long to add this to their malware definitions. Have Mac users finally started running antivirus?
Oh my I feel so sorry for apple security engineer's right now. I'm curious the motivations to release such a serious, and complex, 0day on new years eve!? Makes me wonder who brushed this guy the wrong way, or if he just wants to watch the world burn. That said, seriously impressive work and I give him props.
CVE 2018-0001, it's all about namespaces.
Earlier quoted context omitted.
I had actually submitted to the ZDI, but had written the exploit & write-up in the first place mainly because I like hacking rather than for money. I figured I'd see what offers I'd get anyway, but once I had spent all the time on the write-up, I mainly wanted people to see that, and the amount offered wasn't enough to convince me otherwise. I might've published this earlier even, but my December was kinda busy, firs…
Incredible work. How did you find the bug and how many hours did it take you in total?
Oh my I feel so sorry for apple security engineer's right now. I'm curious the motivations to release such a serious, and complex, 0day on new years eve!? Makes me wonder who brushed this guy the wrong way, or if he just wants to watch the world burn. That said, seriously impressive work and I give him props.
To all the kernel programmers out there, can we get a HN-level ELI5 for this? It looks like a total system compromise is possible. Under what conditions? Any ways to ensure we don't get pwned?
Looks like a Time of Check vs Time of Use (TOCTOU) type vulnerability. User controlled memory is read and used later by kernel space - time in between read and use can be used to overwrite it from user space, typically by exploiting and winning race conditions. I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action…
Oh my I feel so sorry for apple security engineer's right now. I'm curious the motivations to release such a serious, and complex, 0day on new years eve!? Makes me wonder who brushed this guy the wrong way, or if he just wants to watch the world burn. That said, seriously impressive work and I give him props.
MacOS 10.13.2 (which fixes this) has already been out for almost a month so likely nobody will care. Patch your shit people.
Earlier quoted context omitted.
MacOS 10.13.2 (which fixes this) has already been out for almost a month so likely nobody will care. Patch your shit people.
Nah, it doesn't fix the actual vuln - it's just that my exploit doesn't work out of the box because the "hid" binary uses a hardware info leak which doesn't work anymore the way I was doing it. If you patched the "leak" and "hid" binaries together, you'd still get kernel r/w on 10.13.2.