I think he's referring to "Shatter attacks", which is standard terminology. But shatter attacks only work when window messages are passed between a user mode process and a system process. And ever since Windows Vista, they've been completely neutered (desktop apps can't interact with service processes).
The sharing stuff looks to be very similar to the clipboard - you select some stuff in one app, select the "share" system control, it presents a list of apps which can share the thing you selected and you pick the one you want to share with. All of these interactions are user initiated, so I don't see how malware gets involved.
You could always go read the UEFI Specs to see if the UEFI folks have considered this. My guess is that they have already thought of this and it's answered in the specs somewhere.
One of Microsoft's big problems in Office 97-2003 was that people were not noticing features that Microsoft wanted them to use
One of the other motivations about the ribbon: When Microsoft asked users about what features they would like to see in Office, it turns out they asked for features that were already there. But the menu system was so complicated that nobody figured that out.
Jensen Harris (architect of the Ribbon) has an awesome talk about the history of the Office UI that led to the creation of the ribbon on his blog. Search for "why the ui". He also did a video of the story
Actually the \ character was chosen because the "/" character was used in DOS 1.0 for command line switches. And / was used in DOS 1.0 for command line switches because that's what they used in the DEC operating systems (VMS, DECSystem 10, DECSystem 20) from the 1970s. Remember that DOS 1.0 didn't support directories (all files were located at the root of the drive). They added directory support in DOS 2.0. Once / was used as a command line switch delimiter, it couldn't be used as a path separator, so they chose \ instead.
If you're going to blame the "/" character on anyone, it's not MSFT, it's DEC.
Oh and here's a little known fact: DOS (and Windows) allows the user to use either \ or / as a path separator.
To be fair, Lockheed-Martin was hacked because they depended on a 3rd party (RSA) for a critical part of their security infrastructure.
When RSA subsequently had a massive data compromise, instead of letting their customers know what happened, they downplayed the ramifications of the breach. And RSA just won a pwnie for their efforts.
Not that that changes your response in any significant way.
Which gets to the root of the question: If they are allowed to force you to disclose the combination to a safe, is the password to a hard disk any different?
A judge can impose fines as a part of a contempt citation. I suspect that a $1,000,000 fine would be sufficient to force liquidating all or most of your assets.
It's an interesting question of whether a judge can force you to disclose the combination of a safe. Usually the police just force the lock because it's easier, but in principle, they should be able to force you to disclose the combination (if, for instance they have reason to believe there's an anti-tamper device on the safe).
I believe that "the crime of failing to give up your password" is actually the crime of contempt of court.
And that means that the jail sentence is essentially forever. They can literally put you in jail and seize all your assets until you give up the password.
If it's privacy focused, why is it that people don't get the ability to approve who adds them to their circle? There have been a number of people on G+ complaining about this already.
Actually many (most?) applications written for NT 3.5 will still run on Windows 7. Some set of applications need to have compatibility shims added (most of which come with the OS) but yes, they'll still run.
There's certainly a set of applications written for NT 3.5 that won't work on Win7. But that set is vanishingly small.
Ok, I've got to ask: Which people within the borders of Iraq attacked the US?
I totally support and supported the Afghanistan invasion for exactly the reason you listed ("Don't attack the US or let people who attack the US use you as a safe harbour"), and I oppose(d) the Iraq invasion for the exact same reason: As far as I know, nobody who was living in Iraq attacked the US and Iraq didn't harbour any of the people who attacked the US.
There hasn't been an ActiveX vulnerability in a REALLY long time (like maybe a decade?). But ActiveX is a plugin technology. When people talk about ActiveX being insecure, they're really saying that plugins are insecure.
And guess what: Every browser out there (except iOS browsers) has a plugin model. There are only two things that make ActiveX plugins different from any other plugins:
1) A web page can suggest an installation location to use for the plugin (unlike Firefox which recommends that you install plugins from their own site)
2) ActiveX plugins are all digitally signed (on the internet). That means that it's hard for bad guys to deploy vulnerable plugins. This isn't a huge deal because bad guys just use vulnerabilities in existing signed plugins. And they can use #1 to point the user to plugins which have known vulnerabilities.
There are two possible reactions to telling the IT guys about the exploit: (1) you give them enough information to harden their systems proactively (adobe flash scripting has a problem when dealing with flibberjabber elements) or (2) you give them vague information (there's a bug in flash somewhere).
The first is probably enough to give the bad guys enough of a clue for them to figure out the vulnerability and you've just created a 0day. The second isn't enough information for the IT guy to figure out how to protect their systems.
If there was a way for a vendor to tell only their customers about an upcoming issue, without letting the bad guys know, that's another thing. It's exactly why Microsoft created the MAPP which lets antimalware firms know about upcoming patches before they're released.
shutdown-p basically nailed it but I want to dig a bit deeper.
There is no such thing as absolute security. There is no software available to end-users that is 100% secure (there may be very special case scenarios but they're not mainstream). Because of this, security is primarily a risk management problem.
So when you decide to take a patch, you have to weigh the risks of taking the patch (it might break some LOB app) against the risk of *not* taking the patch (you might get hacked).
We make these choices every single day when we get patches from vendors. Sysadmins (who have to keep entire corporations alive) are very risk averse (deploying a patch which shuts down the accounting department is likely to be a career-limiting-move) and that means that they want to make sure that every patch is tested before they deploy it.
So when they see a patch, they need to weight the risks. There is *no* debate that the bad guys reverse engineer patches. They do. That means that once a patch is deployed, the risks of *not* taking it skyrocket.
If you release patches once every few days, that means that sysadmins are constantly putting their line of business apps at risk.
Somewhat off-topic: Every once in a while, someone at work asks about the benefits of moving some internal server from its traditional port to a new port (for instance moving the SMTP server from port 25 to port 9998). The purists always respond with "that's just security by obscurity", to which the pragmatists respond "yeah, but it works to remove certain classes of threats. It won't stop a dedicated attacker who's actively probing your ports, but for most automated attacks, it can be highly effective".
Before the patch is made, many of these exploits are not widely known. Sometimes they are, but normally they aren't.
As I understand it, the risk is that once the patch is published, the bad guys reverse engineer the patch and publish exploits for those patches (usually within 6 hours). So if you delay patching after a patch is made, you put your machines at increased risk. So scheduling an update so that IT folks have time to react is a good thing.
The one exception is when the exploit is published *before* the patch is published. In that case, it makes sense to push an out-of-band patch and to hell with the sysadmins schedule.
Actually for the NTLM hash mentioned in the article, the maximum effective password length is 7 characters.
That's why the NTLM hash was replaced 15 years with NTLMv2 which doesn't have that weakness. And the NTLM hash has been turned off since Windows Vista.
There's no difference between XP and OSX w.r.t. bugs in imaging codecs (and OSX has had plenty of them). You can 0wn the machine with either.
The original assertion was that the OSX's sudo prompt was some how better than Windows UAC prompt or XP's mark-of-the-web. And realistically they aren't really that different.
I truely wish that were true. But if it were, there would be no malware for Windows Vista and Windows 7, since they also require that the user acknowledge a prompt before installation. And there would be no malware for Windows XP either (since it prompts users because a program downloaded from the internet might be dangerous).
Unfortunately a UAC prompt (or sudo prompt) doesn't stop the "I really want to see the dancing bunnies" problem - people will bypass any dialog box you put up to run their application. Consider the Bagle family of malware. They use a password protected Zip file for their payload and even though the user needs to enter the zip file's password, they *still* manage to propogate.
Back in the 1990s when you reported a buffer overflow to a company, their usual answer was "So what, it's only a theoretical vulnerability, it can't be used to attack our product - all you can do is crash my app, you can't get reliable remote code execution".
In the intervening 10 years, most companies no longer feel that way.
To me, the "speculative at best..." comment seems disturbingly familar to the old complaints about the buffer overflows.
That's... Interesting. Buffer overflow attacks were once considered "speculative at best".
Here's a question: What happens when you take drivers which were designed to run only local content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?
The answer is similar to the answer to the question: What happens when you take network services which were designed to run only intranet content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?
We know the answer to the second question: Sasser, Blaster, etc.
Why would the answer to the first question be any different?
And then pray that none of the users of the server ever put any patient data on the server. This means that the calendar data can't include patient names (they're personally identifiable).
Good luck booking appointments without knowing the name of the person who has the appointment.
Slashdot Mirror
I think he's referring to "Shatter attacks", which is standard terminology. But shatter attacks only work when window messages are passed between a user mode process and a system process. And ever since Windows Vista, they've been completely neutered (desktop apps can't interact with service processes).
The sharing stuff looks to be very similar to the clipboard - you select some stuff in one app, select the "share" system control, it presents a list of apps which can share the thing you selected and you pick the one you want to share with. All of these interactions are user initiated, so I don't see how malware gets involved.
You could always go read the UEFI Specs to see if the UEFI folks have considered this. My guess is that they have already thought of this and it's answered in the specs somewhere.
From TFA:
You have to opt into reporting telemetry. So if you don't want your data being uploaded to MSFT, when Windows asks you if you want to opt in, don't.
One of the other motivations about the ribbon: When Microsoft asked users about what features they would like to see in Office, it turns out they asked for features that were already there. But the menu system was so complicated that nobody figured that out.
Jensen Harris (architect of the Ribbon) has an awesome talk about the history of the Office UI that led to the creation of the ribbon on his blog. Search for "why the ui". He also did a video of the story
Actually the \ character was chosen because the "/" character was used in DOS 1.0 for command line switches. And / was used in DOS 1.0 for command line switches because that's what they used in the DEC operating systems (VMS, DECSystem 10, DECSystem 20) from the 1970s. Remember that DOS 1.0 didn't support directories (all files were located at the root of the drive). They added directory support in DOS 2.0. Once / was used as a command line switch delimiter, it couldn't be used as a path separator, so they chose \ instead.
If you're going to blame the "/" character on anyone, it's not MSFT, it's DEC.
Oh and here's a little known fact: DOS (and Windows) allows the user to use either \ or / as a path separator.
Actually, *every* year, the Mac was compromised first.
To be fair, Lockheed-Martin was hacked because they depended on a 3rd party (RSA) for a critical part of their security infrastructure.
When RSA subsequently had a massive data compromise, instead of letting their customers know what happened, they downplayed the ramifications of the breach. And RSA just won a pwnie for their efforts.
Not that that changes your response in any significant way.
And Microsoft will continue to support Windows XP. It's just not going to be providing FREE support, you'll have to have a custom support agreement.
Custom support agreements can go on a LONG time
Which gets to the root of the question: If they are allowed to force you to disclose the combination to a safe, is the password to a hard disk any different?
A judge can impose fines as a part of a contempt citation. I suspect that a $1,000,000 fine would be sufficient to force liquidating all or most of your assets.
It's an interesting question of whether a judge can force you to disclose the combination of a safe. Usually the police just force the lock because it's easier, but in principle, they should be able to force you to disclose the combination (if, for instance they have reason to believe there's an anti-tamper device on the safe).
I believe that "the crime of failing to give up your password" is actually the crime of contempt of court.
And that means that the jail sentence is essentially forever. They can literally put you in jail and seize all your assets until you give up the password.
If it's privacy focused, why is it that people don't get the ability to approve who adds them to their circle? There have been a number of people on G+ complaining about this already.
Actually many (most?) applications written for NT 3.5 will still run on Windows 7. Some set of applications need to have compatibility shims added (most of which come with the OS) but yes, they'll still run.
There's certainly a set of applications written for NT 3.5 that won't work on Win7. But that set is vanishingly small.
Ok, I've got to ask: Which people within the borders of Iraq attacked the US?
I totally support and supported the Afghanistan invasion for exactly the reason you listed ("Don't attack the US or let people who attack the US use you as a safe harbour"), and I oppose(d) the Iraq invasion for the exact same reason: As far as I know, nobody who was living in Iraq attacked the US and Iraq didn't harbour any of the people who attacked the US.
Umm... Flash is an ActiveX control.
There hasn't been an ActiveX vulnerability in a REALLY long time (like maybe a decade?). But ActiveX is a plugin technology. When people talk about ActiveX being insecure, they're really saying that plugins are insecure.
And guess what: Every browser out there (except iOS browsers) has a plugin model. There are only two things that make ActiveX plugins different from any other plugins:
1) A web page can suggest an installation location to use for the plugin (unlike Firefox which recommends that you install plugins from their own site)
2) ActiveX plugins are all digitally signed (on the internet). That means that it's hard for bad guys to deploy vulnerable plugins. This isn't a huge deal because bad guys just use vulnerabilities in existing signed plugins. And they can use #1 to point the user to plugins which have known vulnerabilities.
That's basically it.
There are two possible reactions to telling the IT guys about the exploit: (1) you give them enough information to harden their systems proactively (adobe flash scripting has a problem when dealing with flibberjabber elements) or (2) you give them vague information (there's a bug in flash somewhere).
The first is probably enough to give the bad guys enough of a clue for them to figure out the vulnerability and you've just created a 0day. The second isn't enough information for the IT guy to figure out how to protect their systems.
If there was a way for a vendor to tell only their customers about an upcoming issue, without letting the bad guys know, that's another thing. It's exactly why Microsoft created the MAPP which lets antimalware firms know about upcoming patches before they're released.
shutdown-p basically nailed it but I want to dig a bit deeper.
There is no such thing as absolute security. There is no software available to end-users that is 100% secure (there may be very special case scenarios but they're not mainstream). Because of this, security is primarily a risk management problem.
So when you decide to take a patch, you have to weigh the risks of taking the patch (it might break some LOB app) against the risk of *not* taking the patch (you might get hacked).
We make these choices every single day when we get patches from vendors. Sysadmins (who have to keep entire corporations alive) are very risk averse (deploying a patch which shuts down the accounting department is likely to be a career-limiting-move) and that means that they want to make sure that every patch is tested before they deploy it.
So when they see a patch, they need to weight the risks. There is *no* debate that the bad guys reverse engineer patches. They do. That means that once a patch is deployed, the risks of *not* taking it skyrocket.
If you release patches once every few days, that means that sysadmins are constantly putting their line of business apps at risk.
Somewhat off-topic: Every once in a while, someone at work asks about the benefits of moving some internal server from its traditional port to a new port (for instance moving the SMTP server from port 25 to port 9998). The purists always respond with "that's just security by obscurity", to which the pragmatists respond "yeah, but it works to remove certain classes of threats. It won't stop a dedicated attacker who's actively probing your ports, but for most automated attacks, it can be highly effective".
So yeah, a little "security by obscurity" helps.
Before the patch is made, many of these exploits are not widely known. Sometimes they are, but normally they aren't.
As I understand it, the risk is that once the patch is published, the bad guys reverse engineer the patch and publish exploits for those patches (usually within 6 hours). So if you delay patching after a patch is made, you put your machines at increased risk. So scheduling an update so that IT folks have time to react is a good thing.
The one exception is when the exploit is published *before* the patch is published. In that case, it makes sense to push an out-of-band patch and to hell with the sysadmins schedule.
Actually for the NTLM hash mentioned in the article, the maximum effective password length is 7 characters.
That's why the NTLM hash was replaced 15 years with NTLMv2 which doesn't have that weakness. And the NTLM hash has been turned off since Windows Vista.
There's no difference between XP and OSX w.r.t. bugs in imaging codecs (and OSX has had plenty of them). You can 0wn the machine with either.
The original assertion was that the OSX's sudo prompt was some how better than Windows UAC prompt or XP's mark-of-the-web. And realistically they aren't really that different.
I truely wish that were true. But if it were, there would be no malware for Windows Vista and Windows 7, since they also require that the user acknowledge a prompt before installation. And there would be no malware for Windows XP either (since it prompts users because a program downloaded from the internet might be dangerous).
Unfortunately a UAC prompt (or sudo prompt) doesn't stop the "I really want to see the dancing bunnies" problem - people will bypass any dialog box you put up to run their application. Consider the Bagle family of malware. They use a password protected Zip file for their payload and even though the user needs to enter the zip file's password, they *still* manage to propogate.
Yeah, and how long did it take Microsoft to harden Windows?
Back in the 1990s when you reported a buffer overflow to a company, their usual answer was "So what, it's only a theoretical vulnerability, it can't be used to attack our product - all you can do is crash my app, you can't get reliable remote code execution".
In the intervening 10 years, most companies no longer feel that way.
To me, the "speculative at best..." comment seems disturbingly familar to the old complaints about the buffer overflows.
That's... Interesting. Buffer overflow attacks were once considered "speculative at best".
Here's a question: What happens when you take drivers which were designed to run only local content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?
The answer is similar to the answer to the question: What happens when you take network services which were designed to run only intranet content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?
We know the answer to the second question: Sasser, Blaster, etc.
Why would the answer to the first question be any different?
And then pray that none of the users of the server ever put any patient data on the server. This means that the calendar data can't include patient names (they're personally identifiable).
Good luck booking appointments without knowing the name of the person who has the appointment.