I don't think the transfer occurs explicitly via LAN as other commenters point out, seems more likely Apple acts as a tunnel between the device requesting the keychain and the device authorising (sending) it.
The current vulnerability affects environments where untrusted code already executes. Since applets can be used to upload arbitrary code, it makes sense to block it.
This isn't a political move I don't think, just a common sense mitigatory move to protect people. Web apps running Java are safe from this vulnerability, unless they're accepting user-supplied code and running it.
That's a great clarification and fact that sadly may be lost in the dramatics of the headline, either done on purpose or someone didn't understand before submitting.
The only means I know of for one to reliably detect the image on the screen would be TEMPEST style attacks [1]. I doubt that Capita can afford to buy the necessary equipment, or even views it as economically viable given the volume of letters they sent out - 56 million letters were sent in 2009, for example [2].
I'm not sure if modern TVs will even emit anything obvious since the connection from the decoder to the panel is covered in EMI shielding.
It still seems to contain an unpatched code execution vulnerability from 2010, fixed in CS5 and up [1], I'd say that's "bad enough" to warrant not using it.
At a guess: eventually, yes. I don't think this actually writes over the heap at all - it writes to the .bss section instead. In theory, if left to execute (without the INT3s) it'd probably segfault as soon as it hit the end of the page containing .bss.
malloc could be used to expand the heap, which conveniently appears after .bss. The pointer returned would probably still need to be followed, since heap allocations might not be contiguous (and mprotect needs to be used to mark the pages executable).
Re: the second question, the problem with NX is that it only protects you from overflows where the attacker jumps into the buffer.
Overflows are still exploitable with NX. The attacker instead jumps to a series of fragments of library code[1]. Since libraries will always be executable, there's no problem (aside from the difficulty of finding the right chain of "gadgets").
ASLR goes some way into preventing return oriented programming (ROP) attacks, but it isn't bulletproof.
Your login Keychain is usually unlocked - it's encrypted with a key derived from your password that's held in memory from when you log in.
You can lock your login Keychain (or any other) from Keychain Acccess (/Applications/Utilities) or from the security menu bar item (if you have it added) and you'll be asked for the password rather than asked to "allow" it.
I don't think the article's intention is to convince people it's a con or crush the enthusiasm. Their points aren't illegitimate and their arguments are fair - isn't it prudent to criticise them and see how they respond rather than let them continue unchallenged, especially considering the collective financial contribution involved?
Considering that they already have prototypes together, they've already apparently got something to show. As the article points out there are flaws with what they're offering and questions that need answering.
I'm sure most of the questions and queries can be answered satisfactorily, but the crux is the lack of confirmed titles, which they can't fix themselves.
