That's a legitimate concern, yes, though I still think it's a smaller one - the ratio of attacks with each as the /final/ target shouldn't be effected by SB, after all. So we'll have approximately the same number of attacks against linux systems we had before, because attacking plain linux systems won't help you any more than it did before. Windows vulnerabilities are therefore a new attack vector that the same attackers will use for the same amount of attack demand.
We've been told by MS that they intend to treat themselves the same way as they treat anybody else in this regard, and they've cited some examples that indicate some extent of ernesty and honesty in this regard. How it all works out is yet to be seen, but on the face they do appear to have considered this rationally and understood that if they don't use the same process for windows exploits, it hurts them just as much as it hurts us. They do have some track record - specifically regarding driver signing through winqual, which is essentially the same mechanism we expect to be using[1].
Our understanding of the process does include the fact that they believe in using the nuance of the mechanisms for blacklisting. Those being, in order of severity 1) blacklisting hashes of specific binaries after a (relatively) short notice period after exploits are found in the wild; 2) re-issuing individual signing keys[2], pushing them out, providing a window to push out new signed binaries, and then pushing out a blacklist entry for the old signing keys[3]; and 3) doing the dance from #2 on a bigger scale with CA certs if that becomes necessary.
[1] See this document (http://www.uefi.org/learning_center/UEFI_Plugfest_2011Q4_P6_Microsoft.pdf) for more details.
[2] The way signing works is that each signer is issued a key by the CA, though the CA keeps the keys. You authenticate with a smartcard[2] and upload a binary for the CA to sign with your assigned key. You receive the signed binary in return.
[3] This is the process that would be taken when something like this exploit (http://en.wikipedia.org/wiki/Stuxnet#Windows_infection) happens.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
Re: Complexity
Date: 2012-05-31 03:16 pm (UTC)We've been told by MS that they intend to treat themselves the same way as they treat anybody else in this regard, and they've cited some examples that indicate some extent of ernesty and honesty in this regard. How it all works out is yet to be seen, but on the face they do appear to have considered this rationally and understood that if they don't use the same process for windows exploits, it hurts them just as much as it hurts us. They do have some track record - specifically regarding driver signing through winqual, which is essentially the same mechanism we expect to be using[1].
Our understanding of the process does include the fact that they believe in using the nuance of the mechanisms for blacklisting. Those being, in order of severity 1) blacklisting hashes of specific binaries after a (relatively) short notice period after exploits are found in the wild; 2) re-issuing individual signing keys[2], pushing them out, providing a window to push out new signed binaries, and then pushing out a blacklist entry for the old signing keys[3]; and 3) doing the dance from #2 on a bigger scale with CA certs if that becomes necessary.
[1] See this document (http://www.uefi.org/learning_center/UEFI_Plugfest_2011Q4_P6_Microsoft.pdf) for more details.
[2] The way signing works is that each signer is issued a key by the CA, though the CA keeps the keys. You authenticate with a smartcard[2] and upload a binary for the CA to sign with your assigned key. You receive the signed binary in return.
[3] This is the process that would be taken when something like this exploit (http://en.wikipedia.org/wiki/Stuxnet#Windows_infection) happens.
-- pjones