I'll be interested in seeing how that works out. Microsoft thought the same thing - they thought that an implementation which used a hash table to store compression data wouldn't infringe on a patent that used a binary tree to store compression data. 120 million dollars later, Microsoft was proven wrong[1]
Simply tweaking an algorithm (changing a block size from 8x8 to 4x4) isn't necessarily enough to avoid a patent.
[1] And yeah, I know that there aren't exact parallels with Stac vs MSFT here. But elements of Stac vs MSFT apply.
Except that TFA says that what MSFT did was to backport the Vista change to XP (which it did two years ago). It's been available for XP all that time. What's changed is that they've collected enough data to make them believe that pushing it to more users is a good thing.
When MSFT first announced they were disabling autorun on Win7, people screamed that the world was going to end. Well, it didn't.
Part of the reason that they were able to make this change is that they've had two years of operational experience with Windows 7 where nothing horrible happened.
There's a decent post on the MSRC blog that describes the logic behind the change.
You got me - the text I quoted wasn't in 2822, it was in 2821.
However it's important to realize RFC 5233 is not the spec for either the SMTP protocol or the email format which define internet email. It's an unrelated protocol which defines an extension to RFC 5228 that is *optional*. It's totally possible and reasonable to implement an MTA/MUA combination that just supports 5321 and 5322 without supporting either 5233 or 5228. In fact, I'd bet that most SMTP MTAs don't.
If your turnkey spam gateway advertised support for RFC 5323/RFC 5228 and then didn't follow the RFC, then you'd have a point (more on that in the next paragraph). But don't criticize the spam gateway for ignoring RFCs that aren't required for email delivery. You'll note that RFC 5323/RFC 5228 are not listed as a normative reference for either RFC 5321 or RFC 5322. That means that a server that acts as an MUA/MTA does not have to support RFC 5323 (normative references to a standard define the other protocols which must be implemented in order to successfully implement the standard).
Btw, reading RFC 5323 was interesting. I've been out of the internet email business for a decade (which is why I'm not up on the actual RFC #s) so I wasn't familar with it. It turns out that RFC 5323 doesn't define the + convention except to use it as an example of sub-addressing (as you pointed out). RFC 5323 in fact has very little to do with what is allowed in an email message. Instead it defines a set of extensions to the SIEVE filtering language (RFC 5228) that allow for ":user" and ":detail" sub addressing elements. Now SIEVE is involved in email delivery, it's a post-processor that's applied to email messages. But the SIEVE RFC doesn't define the "+" convention either.
Ok, I'l bite. Where in 5233 does it document the + addressing?
The only text I could find about local-part has:
The local-part portion is a domain-dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox.
There is text in 5231 about local-part:
"local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
which appears to be really close to the text I quoted in my original answer.
The only use of "+" in RFC 5321 that isn't part of a text diagram is John Klemsin's email address, the only use of + in RFC 5322 is in text diagrams and a discussion of timestamps.
The critical point here is that "+" is *not* a standard or part of a standard. So claiming that the author of the spamwall is ignoring the RFCs is incorrect - the relevent RFCs are mute about the "+" convention.
Mod parent up +1 Funny. After all, if the parent had actually *read* the RFC, they would know that the RFC explicitly states that:
"Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."
That means that the spam filter is following the RFC. The + address is a convention of a number of email systems but Foo+Bar@domain.com and Foo@domain.com are unrelated email addresses according to RFC2822.
Google says that they don't use this feedback to improve their search results. But Google *does* spy on users making Bing searches and tracks where they click.
Your question stumped me, so I asked the experts. It turns out that it *is* possible to disable NTLM in Windows 7/Server 2008 R2 with the "Restrict NTLM" option. But my expert pointed out that enabling this option isn't sufficient to fix pass-the-hash attacks. It turns out that pass-the-hash attacks (or rather pass-the-tgt attacks) also can work against Kerberos, it's just that there aren't any tools available to mount them. But the attack works.
Digging in deeper, the only reason Windows is considered vulnerable to pass-the-hash is that Windows is the only major OS where tools to automate pass-the-hash attacks are available. Every major OS out there is vulnerable to pass-the-hash attacks, the issue isn't unique to Microsoft (and thus the existance of pass-the-hash attacks not because 'microsoft developers are clueless').
One other thought: pass-the-hash attacks require that the local user be an administrator. If you want to defeat pass-the-hash attacks, don't allow your users to be local administrators. Microsoft's best practices have strongly recommended that users not run as administrators since well before Windows 2000. And to preempt your next question: you're right, Microsoft only made it possible for users to run as non-admins in Windows XP and even then it was challenging. It wasn't until Windows Vista that they enabled something that resembled standard-users as the default (which in turn forced software developers to change their applications so that they'll run as standard users).
Pass the hash is only relevant in single sign-on environments (because the hash is password equivilant). For Microsoft that means domain joined, and if you're domain joined you use Kerberos (unless you have legacy NT4 machines on your network, in which case you have bigger issues than pass-the-hash attacks).
In non domain environments, each machine has its own account database. Since the pass-the-hash attacks all appear to require that you have full access to the account database, all you're doing is getting a hash for something that's only valid on the current machine and that you already can access.
Pass the hash - you mean the attack technique that Microsoft fixed in Windows 2000 with the addition of Kerberos? You're right that Microsoft didn't stop using the weak NTLM hashes until Windows Vista, but it's not like Microsoft hasn't offered a solution for over 10 years.
If you want to pick on Microsoft for stupid security decisions, instead of pass the hash, why not pick on credential reflection attacks. They're a much better example of Microsoft being clueless (or more accurately, people who depended on integrated windows authentication being clueless, Microsoft included).
I'm not commenting on Amazon's actions - they need to do more (proactively warning customers with really old passwords would be a good start) but it's good that the fix is easy.
I was making a comment about the double standard implicit in the thread - there are a lot of "it's ok that Amazon screwed up here because it's easy to make such a mistake" attitude. On the other hand, 20+ years ago MSFT made essentially the same mistake (and fixed it 15+ years ago) and it's still being used as an example of why "Microsoft fundamentally doesn't get security".
In hindsight, I probably shouldn't have picked on your comment to mention it - your response was in fact informative and if I had mod points (and I hadn't commented) I'd have modded it up.
When Microsoft did essentially the same thing it was touted (and is still being touted) as being an example of why Microsoft doesn't get security.... Somehow it was inexcusable to make this mistake in 1987 (when the LM hash was invented) but it's "ok" to do it in 2011?
According to stepto (XBox director of enforcement) he did provide proof to the mother. He has no obligation to provide that proof to anyone else.
Re:The Complaint and Patents
on
Microsoft Sues TiVo
·
· Score: 5, Informative
TFS leaves out one critical point in TFA. This complaint is in reaction to TiVo suing AT&T (and Microsoft since the software in question was written by Microsoft (MediaRoom)).
This isn't as simple as "big bad Microsoft is suing poor little TiVo". According to TFA, this is just another volley in a protracted lawsuit.
Ehhh... Microsoft doesn't own the patents for H.264. It owns *some* of the patents, but not all of them.
The only entity who could release the patents is the patent owner, the MPEG-LA.
I don't know why you mentioned MSFT in this comment... Even the grandparent talks about Google's action as being a forcing function to convince Microsoft to drop H.264 support.
Running as a non-admin has been a Windows logo requirement since 2000. So MSFT has been asking people to write for non admin accounts for over a decade. They've also provided resources to help developers switch to non admin accounts.
The problem is that developers are lazy. Even though getting an app to run as a non-admin is good for your users and it isn't that difficult (basically you need to avoid writing to system-owned locations), people won't do it without a forcing function.
That's actually why UAC exists - it acts as a forcing function on developers. If they write their apps so they can run without being an admin, they can avoid the annoying popup. If they don't, they can still run but their customers get annoyed by the popup every time their app runs.
And it's really not that challenging to get the vast majority of the apps out there running as a non-admin user (I've done it before). In reality, very few apps require admin privileges to do their job and for them, there are ways that it can be managed (bifurcate your app into a UI element and a demand-start service that runs as LocalSystem (you can even use a COM object for this), then IPC to the service when you want it to do something).
The job of a structural engineer is to analyze a design and render opinions about the amount of stress a particular structure can withstand and to design structures which can resist particular loads. In the context I described (an architect designing a house), you're right that a part of their job is similar to that of a tester.
That may be. I'm just parroting back what I was taught in college in my software engineering course. I've never worked as a mechanical or structural engineer.
But I do know that much engineering work is pretty-much cookie-cutter work.
Probably true. But for the vast number of jobs an engineer does, the work is very straightforward.
If I'm an architect and I want to know if my design is structurally sound, I know that I can hire a structural engineer for n hours of work and they'll be able to answer my question - and the number n is pretty much the same for all structural engineers. I'm not aware of any software engineers (and I am one) who schedule work by the hour (they may bill by the hour but they don't schedule by the hour).
I had a friend in college who got a double major in art and electrical engineering. When I asked her why she was working in such different fields, she responded that to her art and electrical engineering were both forms of art.
For some reason this has stuck with me for decades (yeah, I'm an old guy).
There's one huge difference that makes programming different from engineering. Engineering is predictable - a mechanical, structural or civil engineer can accurately schedule the amount of time needed to produce a unit of work.
Programming isn't nearly as predictable - even the best developers I know can only schedule work to a tolerance of a couple of days. Invariably something turns out to be harder (or easier) than it was originally planned.
There is 100% disclosure only if you audit every single change to the kernel to determine if the fix is a fix for a security vulnerability or not.
Don't forget that applying a bug fix has a level of risk associated with it - every bug fix has the potential for regressing some mission critical functionality. The OS vendor attempts to ensure that nothing is broken by the patch, but it *does* happen.
As a customer deciding to take a patch, I need to assess if the risk associated with taking the patch is greater than the risk of the that the patch fixes.
Knowing that by not taking a patch I put my data (and my customers data) at risk (which is the case for security bugs) allows me to give a higher priority to the patch.
The reason that MSFT (and AAPL) disclose their kernel vulnerabilities up is to give their customers this critical information. For Linux distributions, the only way to know if a patch fixes a security related problem is to audit the source code.
For most users (and organizations) the Linux way is simply too much work.
The Linux approach moves the responsibility for determining if a bug is a security bug from the developer (who best knows the code and potential consequences of a bug) to the end-user. And as the end user, how would you know if (for example) the addition of:
MD_Update(&m,buf,j);
is a security bug fix (or more importantly that the removal of that code would introduce a critical vulnerability in the Debian random number generator)?
So while App Store sales are through the roof, Apple's certainly not making a killing from them. But that's never been the point, anyway. Like iTunes itself, the App Store's purpose is to drive hardware sales. It's a secondary business.
As I understand it, Apple doesn't make any profit from their app stores. Seriously. All the revenue they get barely pays for the cost of running the store.
For Apple, the app store is a way of providing value to the expensive devices that they sell. I'm not sure what MSFT's motive is.
Slashdot Mirror
I'll be interested in seeing how that works out. Microsoft thought the same thing - they thought that an implementation which used a hash table to store compression data wouldn't infringe on a patent that used a binary tree to store compression data. 120 million dollars later, Microsoft was proven wrong[1]
Simply tweaking an algorithm (changing a block size from 8x8 to 4x4) isn't necessarily enough to avoid a patent.
[1] And yeah, I know that there aren't exact parallels with Stac vs MSFT here. But elements of Stac vs MSFT apply.
Except that TFA says that what MSFT did was to backport the Vista change to XP (which it did two years ago). It's been available for XP all that time. What's changed is that they've collected enough data to make them believe that pushing it to more users is a good thing.
When MSFT first announced they were disabling autorun on Win7, people screamed that the world was going to end. Well, it didn't.
Part of the reason that they were able to make this change is that they've had two years of operational experience with Windows 7 where nothing horrible happened.
There's a decent post on the MSRC blog that describes the logic behind the change.
You got me - the text I quoted wasn't in 2822, it was in 2821.
However it's important to realize RFC 5233 is not the spec for either the SMTP protocol or the email format which define internet email. It's an unrelated protocol which defines an extension to RFC 5228 that is *optional*. It's totally possible and reasonable to implement an MTA/MUA combination that just supports 5321 and 5322 without supporting either 5233 or 5228. In fact, I'd bet that most SMTP MTAs don't.
If your turnkey spam gateway advertised support for RFC 5323/RFC 5228 and then didn't follow the RFC, then you'd have a point (more on that in the next paragraph). But don't criticize the spam gateway for ignoring RFCs that aren't required for email delivery. You'll note that RFC 5323/RFC 5228 are not listed as a normative reference for either RFC 5321 or RFC 5322. That means that a server that acts as an MUA/MTA does not have to support RFC 5323 (normative references to a standard define the other protocols which must be implemented in order to successfully implement the standard).
Btw, reading RFC 5323 was interesting. I've been out of the internet email business for a decade (which is why I'm not up on the actual RFC #s) so I wasn't familar with it. It turns out that RFC 5323 doesn't define the + convention except to use it as an example of sub-addressing (as you pointed out). RFC 5323 in fact has very little to do with what is allowed in an email message. Instead it defines a set of extensions to the SIEVE filtering language (RFC 5228) that allow for ":user" and ":detail" sub addressing elements. Now SIEVE is involved in email delivery, it's a post-processor that's applied to email messages. But the SIEVE RFC doesn't define the "+" convention either.
Ok, I'l bite. Where in 5233 does it document the + addressing?
The only text I could find about local-part has:
There is text in 5231 about local-part:
which appears to be really close to the text I quoted in my original answer.
The only use of "+" in RFC 5321 that isn't part of a text diagram is John Klemsin's email address, the only use of + in RFC 5322 is in text diagrams and a discussion of timestamps.
The critical point here is that "+" is *not* a standard or part of a standard. So claiming that the author of the spamwall is ignoring the RFCs is incorrect - the relevent RFCs are mute about the "+" convention.
Mod parent up +1 Funny. After all, if the parent had actually *read* the RFC, they would know that the RFC explicitly states that:
That means that the spam filter is following the RFC. The + address is a convention of a number of email systems but Foo+Bar@domain.com and Foo@domain.com are unrelated email addresses according to RFC2822.
Can you confirm this? Apparently network traces indicate that Google collects and corrolates Bing searches with the clicked on results.
Google says that they don't use this feedback to improve their search results. But Google *does* spy on users making Bing searches and tracks where they click.
Your question stumped me, so I asked the experts. It turns out that it *is* possible to disable NTLM in Windows 7/Server 2008 R2 with the "Restrict NTLM" option. But my expert pointed out that enabling this option isn't sufficient to fix pass-the-hash attacks. It turns out that pass-the-hash attacks (or rather pass-the-tgt attacks) also can work against Kerberos, it's just that there aren't any tools available to mount them. But the attack works.
Digging in deeper, the only reason Windows is considered vulnerable to pass-the-hash is that Windows is the only major OS where tools to automate pass-the-hash attacks are available. Every major OS out there is vulnerable to pass-the-hash attacks, the issue isn't unique to Microsoft (and thus the existance of pass-the-hash attacks not because 'microsoft developers are clueless').
One other thought: pass-the-hash attacks require that the local user be an administrator. If you want to defeat pass-the-hash attacks, don't allow your users to be local administrators. Microsoft's best practices have strongly recommended that users not run as administrators since well before Windows 2000. And to preempt your next question: you're right, Microsoft only made it possible for users to run as non-admins in Windows XP and even then it was challenging. It wasn't until Windows Vista that they enabled something that resembled standard-users as the default (which in turn forced software developers to change their applications so that they'll run as standard users).
Pass the hash is only relevant in single sign-on environments (because the hash is password equivilant). For Microsoft that means domain joined, and if you're domain joined you use Kerberos (unless you have legacy NT4 machines on your network, in which case you have bigger issues than pass-the-hash attacks).
In non domain environments, each machine has its own account database. Since the pass-the-hash attacks all appear to require that you have full access to the account database, all you're doing is getting a hash for something that's only valid on the current machine and that you already can access.
Pass the hash - you mean the attack technique that Microsoft fixed in Windows 2000 with the addition of Kerberos? You're right that Microsoft didn't stop using the weak NTLM hashes until Windows Vista, but it's not like Microsoft hasn't offered a solution for over 10 years.
If you want to pick on Microsoft for stupid security decisions, instead of pass the hash, why not pick on credential reflection attacks. They're a much better example of Microsoft being clueless (or more accurately, people who depended on integrated windows authentication being clueless, Microsoft included).
I'm not commenting on Amazon's actions - they need to do more (proactively warning customers with really old passwords would be a good start) but it's good that the fix is easy.
I was making a comment about the double standard implicit in the thread - there are a lot of "it's ok that Amazon screwed up here because it's easy to make such a mistake" attitude. On the other hand, 20+ years ago MSFT made essentially the same mistake (and fixed it 15+ years ago) and it's still being used as an example of why "Microsoft fundamentally doesn't get security".
In hindsight, I probably shouldn't have picked on your comment to mention it - your response was in fact informative and if I had mod points (and I hadn't commented) I'd have modded it up.
When Microsoft did essentially the same thing it was touted (and is still being touted) as being an example of why Microsoft doesn't get security.... Somehow it was inexcusable to make this mistake in 1987 (when the LM hash was invented) but it's "ok" to do it in 2011?
Just sayin'
According to stepto (XBox director of enforcement) he did provide proof to the mother. He has no obligation to provide that proof to anyone else.
TFS leaves out one critical point in TFA. This complaint is in reaction to TiVo suing AT&T (and Microsoft since the software in question was written by Microsoft (MediaRoom)).
This isn't as simple as "big bad Microsoft is suing poor little TiVo". According to TFA, this is just another volley in a protracted lawsuit.
Here's Microsoft's response to that: http://blogs.msdn.com/b/giorgio/archive/2011/01/14/building-great-browsers-together.aspx
Ehhh... Microsoft doesn't own the patents for H.264. It owns *some* of the patents, but not all of them.
The only entity who could release the patents is the patent owner, the MPEG-LA.
I don't know why you mentioned MSFT in this comment... Even the grandparent talks about Google's action as being a forcing function to convince Microsoft to drop H.264 support.
Wait, you're going to tout the "standards compliance" of *Netscape*? Ummm... Netscape was just as bad as IE at standards compliance...
Running as a non-admin has been a Windows logo requirement since 2000. So MSFT has been asking people to write for non admin accounts for over a decade. They've also provided resources to help developers switch to non admin accounts.
The problem is that developers are lazy. Even though getting an app to run as a non-admin is good for your users and it isn't that difficult (basically you need to avoid writing to system-owned locations), people won't do it without a forcing function.
That's actually why UAC exists - it acts as a forcing function on developers. If they write their apps so they can run without being an admin, they can avoid the annoying popup. If they don't, they can still run but their customers get annoyed by the popup every time their app runs.
And it's really not that challenging to get the vast majority of the apps out there running as a non-admin user (I've done it before). In reality, very few apps require admin privileges to do their job and for them, there are ways that it can be managed (bifurcate your app into a UI element and a demand-start service that runs as LocalSystem (you can even use a COM object for this), then IPC to the service when you want it to do something).
The job of a structural engineer is to analyze a design and render opinions about the amount of stress a particular structure can withstand and to design structures which can resist particular loads. In the context I described (an architect designing a house), you're right that a part of their job is similar to that of a tester.
That may be. I'm just parroting back what I was taught in college in my software engineering course. I've never worked as a mechanical or structural engineer.
But I do know that much engineering work is pretty-much cookie-cutter work.
Probably true. But for the vast number of jobs an engineer does, the work is very straightforward.
If I'm an architect and I want to know if my design is structurally sound, I know that I can hire a structural engineer for n hours of work and they'll be able to answer my question - and the number n is pretty much the same for all structural engineers. I'm not aware of any software engineers (and I am one) who schedule work by the hour (they may bill by the hour but they don't schedule by the hour).
I had a friend in college who got a double major in art and electrical engineering. When I asked her why she was working in such different fields, she responded that to her art and electrical engineering were both forms of art.
For some reason this has stuck with me for decades (yeah, I'm an old guy).
There's one huge difference that makes programming different from engineering. Engineering is predictable - a mechanical, structural or civil engineer can accurately schedule the amount of time needed to produce a unit of work.
Programming isn't nearly as predictable - even the best developers I know can only schedule work to a tolerance of a couple of days. Invariably something turns out to be harder (or easier) than it was originally planned.
There is 100% disclosure only if you audit every single change to the kernel to determine if the fix is a fix for a security vulnerability or not.
Don't forget that applying a bug fix has a level of risk associated with it - every bug fix has the potential for regressing some mission critical functionality. The OS vendor attempts to ensure that nothing is broken by the patch, but it *does* happen.
As a customer deciding to take a patch, I need to assess if the risk associated with taking the patch is greater than the risk of the that the patch fixes.
Knowing that by not taking a patch I put my data (and my customers data) at risk (which is the case for security bugs) allows me to give a higher priority to the patch.
The reason that MSFT (and AAPL) disclose their kernel vulnerabilities up is to give their customers this critical information. For Linux distributions, the only way to know if a patch fixes a security related problem is to audit the source code.
For most users (and organizations) the Linux way is simply too much work.
The Linux approach moves the responsibility for determining if a bug is a security bug from the developer (who best knows the code and potential consequences of a bug) to the end-user. And as the end user, how would you know if (for example) the addition of:
MD_Update(&m,buf,j);
is a security bug fix (or more importantly that the removal of that code would introduce a critical vulnerability in the Debian random number generator)?
And that doesn't help the end-user at all.
The best one I was able to find was this one:
http://news.cnet.com/8301-13579_3-20008540-37.html
Money quote:
As I understand it, Apple doesn't make any profit from their app stores. Seriously. All the revenue they get barely pays for the cost of running the store.
For Apple, the app store is a way of providing value to the expensive devices that they sell. I'm not sure what MSFT's motive is.