Hacker News Reader

Since the source code is available, might it be possible to produce a hot patch to the binary so that those of us running Mavericks won't have to go through the next few days or weeks with our pants down? It would be a simple matter of finding the JMP instruction generated by the second GOTO and replacing it with no-ops. How hard could it be,at least for someone who actually knows their way around OS X binary file formats?

View on HN

Likely the compiler will have optimized away the rest of the function as dead-code, so it's not as simple as just getting rid of the unconditional jump.

Ah, right. Good point.

If the code to Security.framework is complete and builds, we might not need to patch the binary directly.

It appears to be in a cursory glance. Loaded for me in Xcode. That said, signing the security framework would be another issue ;-) I can't imagine apple would let malware replace security binaries that easily.

It's almost buildable for me: https://news.ycombinator.com/item?id=7283601

I think it'd break one of the binaries, but I could replace that with the real one.

(Caveat: I haven't tried this myself!) Here's the analysis and an experimental patch from @i0n1c for the 64bit version of Mavericks' Security.framework (32-bit remains unpatched): http://sektioneins.de/blog/14-02-22-Apple-SSL-BUG.html

Reply on news.ycombinator.com