Two years ago, nobody had heard of HTTP response splitting attacks. So training/planning for security wouldn't include them.
Two years ago, heap overrun attacks were almost always considered to be DOS attacks, not exploitable buffer overruns.
Eighteen months ago, people didn't realize that you could mount a viable attack by setting a null byte off the end of a static buffer (they thought you needed to be able to write the attack payload there).
Six months ago, people didn't realize that a DOS attack that occurred through a constant vtbl pointer would be exploitable.
Six months ago, people thought it was ok to use MD5 as a message digest.
The threat landscape constantly changes, practices that were previously thought to be safe are determined to be unsafe all the time. So you need to ensure that you build this into your security process. If your process doesn't continually adopt to new threats, you're going to lose the game.
Except that formal verification of software doesn't scale. Formal proofs of correctness are VERY hard to generate, and once you're dealing with a system with more than a couple of hundred lines of code or more than one thread of execution, they fall apart.
There are numerous examples of theoretically "proven correct" software that wasn't. For a simple example, consider the Mars Pathfinder suffered from a priority inversion bug.
Formally proving the correctness of a large system is not as easy as your intro to CS class made it out to be.
The minimum reasonable button set for a TV tuner and DVR equipped remote is something around 20.
You've got 10 buttons for a direct access pad, channel up/down, volume up/down, a dpad (5 buttons), and a power button. You probably need a guide button too, that's 21 buttons.
If you decide you don't want to force the user to use the guide, you can get back 10 buttons (to 11), and it's possible to use the dpad for the volume/channel up/down buttons (dpad up/down becomes volume up/down, dpad left/right become channel up/down).
But your UI gets REALLY complicated really quickly - the more you overload the buttons, the more complicated the UI gets. And you start to lose functionality. For instance, if you implement volume up/down using the dpad, then you can't change the volume while changing the channel.
If all you're doing is cloning the iPod UI (which is basically all that FrontRow is), then 6 buttons is probably sufficient. But once you start doing more than that, you're going to to find 6 buttons VERY constraining.
If your 16bit line-of-business application all of a sudden stopped working on Windows, I suspect you'd be a bit upset. And yes, there are a boatload of 16bit LOB applications, enough that Microsoft is willing to keep the 16bit stuff around. For whatever reason, many installers are 16bit apps, for example.
OTOH, Win64 doesn't support 16 bit apps (as far as I know).
Interesting. They've got them installed in the mens room at Center House in Seattle Center, and I use them just about every week, I've never noticed the "faint odor of urine".
Center House is a pretty high traffic area too, fwiw.
I'm not sure if they actually save money or not, but...
It doesn't even work on current Intel and AMD processors. But as long as your code is running on a uniprocessor platform, you'll never see the problem (because the write-ordering issues are hidden on a single processor).
This code may very well work in the narrow scenario in which you're using it, but it's NOT a general purpose solution to the problem.
That code makes a huge fundimental assumption, that write order is preserved. In other words, if you do:
Write to location 3 on processor 1 (take the lock) Read from location 30 on processor 1 (do stuff with the lock held) Read from location 3 on processor 2 (check the lock)
that the reads and writes will appear in order. On ALL modern processors, this assumption is not true, it's possible for the write to location 3 to occur AFTER the read from location 3 on processor 2. It works great on single processor machines, but fails on MP machines.
In order to make the code work, you need to put a memoy write barrier after the write to location 3, this will force the write to be flushed from the cache.
If it could be shown that a significant change occurred in a species without a series of intervening mutations, that would falsify evolution.
Of course, the challenge would then be on the discoverer to propose an alternative that would also explain all of the things that evolution describes, and all the experimental evidence supporting it.
This HAS happened in the past. For instance, when Einstein proposed his Theory of Relativity, he threw out Newtons Theories of motion. But Einstein's theory was able to supercede Newtons theory by including all the existing experiments - Einstein's theory only becomes significant when your dealing with velocities close to the speed of light, and none of the previous experiments validating Newtons theories were executed close to that speed.
There is a huge volume of scientific evidence in favor of Evolution, just as there was a significant body of evidence in favor of Newtons theories of motion. Just like Newtons theories, it would be quite hard to falsify it, but it COULD happen.
Never said that NT hasn't had stuff from BSD before - it's well known that some of the TCP utilities in XP still have BSD copyrights on them.
But none of the items listed by the GP is evidence that the Vista kernel was rewritten based on BSD. All of the technologies cited have been in Windows for a very long time.
So you have three reports on/. One of them describes a feature that's been in Windows since NT 3.1 (and exposed as a public API since Windows 2000) (symlinks). The other describes an existing feature that's been available for Windows since NT 4 and is now apparently being included in the OS base (SFU). And the third that describes a feature that's been available for Windows since NT 3.1 (and made really usable in XP) (limited rights user accounts).
From these three technologies, all of which are over 10 years old, the poster decides that Microsoft rewrote the Vista OS based on BSD.
Anti-Virus doesn't help in the "connected to the internet for minutes" scenario. It helps in the "I downloaded this cool pr0n app from the internet" case.
Firewalls help in the "connected to the internet for minutes" case. And XP has one built in and enabled by default for well over a year now.
I'd like to see the "connected to the internet for minutes" numbers for XP SP2, to be honest.
#2 above needs to read:
2) It would drive all software development to big companies (because they have enough cash on hand to cover the liability of their employees).
But what if the author of the defect is working on an open source project? And they're NOT employeed by a company? Who's held liable? Their employeer? The people who produced the distro?
What if they're a student at a university? Does the university have to accept liability?
Making the company that makes the product be liable for defects in the product would either do one of two things:
1) Drive all software development to be open source (because you're saying that individuals who contribute to open source projects will avoid all liability), or
2) It would drive all software development to big companies.
I'm with #2, because once you decide to adopt the idea that authors of software are held liable for their software's defects, there is NO WAY that they'd let a loophole as big as #1 exist - someone's got to be held responsible, and if there's no company to blame, they're got to find someone.
And the person who wrote the code that introduced the defect looks like a pretty good candidate to me.
Here's the thing. If the binaries had been digitally signed by the mozilla foundation, then the hacker's attempt to change the file would have broken the digital signature.
Without signatures on binaries, there's no way of knowing if the binary you download is the one that the author intended it to be.
Re:OSS is *good* for competition and innovation
on
Trouble With Open Source?
·
· Score: 2, Insightful
This is so true - OSS is a force for commoditization. But you missed the corrolary to point.
Commodities aren't innovative. By their very nature, commodities can't be.
When was the last time you saw innovation in rice? How about innovation in breakfast cereal?
The key thing about a commodity is that they are 100% fungible. Each one is just as good as the next.
This totally precludes innovation - if it was innovative, it wouldn't be a commodity.
No, they can't. The changes in Microsoft's patches are reverse engineered. Exploits are written against a patch within 72 hours. Once the patch is released, you MUST deploy it or your are vulnerable to every bot author who wants to add your machine to their zombie army.
This is SO true. Zotob was reverse engineered and released only two or three days after the patch was released.
Slashdot Mirror
What good is the data if it's encrypted?
Good luck decrypting a hard disk which has been encrypted with blowfish (or 3DES, or whatever) using a 4096 bit key.
Email. 10,000 users at 500,000,000 bytes of email storage each means 5TB of data to hold the email.
Since most email messages are in the 1-5K range, storing that much data in separate files is a disaster.
It's better to split the database up into a couple of hundred hundred G or so databases.
Also satellite imagery take up a TON of disk space.
Two years ago, nobody had heard of HTTP response splitting attacks. So training/planning for security wouldn't include them.
Two years ago, heap overrun attacks were almost always considered to be DOS attacks, not exploitable buffer overruns.
Eighteen months ago, people didn't realize that you could mount a viable attack by setting a null byte off the end of a static buffer (they thought you needed to be able to write the attack payload there).
Six months ago, people didn't realize that a DOS attack that occurred through a constant vtbl pointer would be exploitable.
Six months ago, people thought it was ok to use MD5 as a message digest.
The threat landscape constantly changes, practices that were previously thought to be safe are determined to be unsafe all the time. So you need to ensure that you build this into your security process. If your process doesn't continually adopt to new threats, you're going to lose the game.
Except that formal verification of software doesn't scale. Formal proofs of correctness are VERY hard to generate, and once you're dealing with a system with more than a couple of hundred lines of code or more than one thread of execution, they fall apart.
There are numerous examples of theoretically "proven correct" software that wasn't. For a simple example, consider the Mars Pathfinder suffered from a priority inversion bug.
Formally proving the correctness of a large system is not as easy as your intro to CS class made it out to be.
Typo:
If you decide you don't want to force the user to use the guide
Should be:
If you decide you don't want to let the user directly address channels and instead force them to use the guide
The minimum reasonable button set for a TV tuner and DVR equipped remote is something around 20.
You've got 10 buttons for a direct access pad, channel up/down, volume up/down, a dpad (5 buttons), and a power button. You probably need a guide button too, that's 21 buttons.
If you decide you don't want to force the user to use the guide, you can get back 10 buttons (to 11), and it's possible to use the dpad for the volume/channel up/down buttons (dpad up/down becomes volume up/down, dpad left/right become channel up/down).
But your UI gets REALLY complicated really quickly - the more you overload the buttons, the more complicated the UI gets. And you start to lose functionality. For instance, if you implement volume up/down using the dpad, then you can't change the volume while changing the channel.
If all you're doing is cloning the iPod UI (which is basically all that FrontRow is), then 6 buttons is probably sufficient. But once you start doing more than that, you're going to to find 6 buttons VERY constraining.
I love it when people bring up those two hoary urban legends...
Check out: http://www.stellaawards.com/bogus.html, it's got a bunch of info on these (and more) urban legends.
If your 16bit line-of-business application all of a sudden stopped working on Windows, I suspect you'd be a bit upset. And yes, there are a boatload of 16bit LOB applications, enough that Microsoft is willing to keep the 16bit stuff around. For whatever reason, many installers are 16bit apps, for example.
OTOH, Win64 doesn't support 16 bit apps (as far as I know).
Interesting. They've got them installed in the mens room at Center House in Seattle Center, and I use them just about every week, I've never noticed the "faint odor of urine".
Center House is a pretty high traffic area too, fwiw.
I'm not sure if they actually save money or not, but...
It doesn't even work on current Intel and AMD processors. But as long as your code is running on a uniprocessor platform, you'll never see the problem (because the write-ordering issues are hidden on a single processor).
This code may very well work in the narrow scenario in which you're using it, but it's NOT a general purpose solution to the problem.
The PhD is STILL right.
That code makes a huge fundimental assumption, that write order is preserved. In other words, if you do:
Write to location 3 on processor 1 (take the lock)
Read from location 30 on processor 1 (do stuff with the lock held)
Read from location 3 on processor 2 (check the lock)
that the reads and writes will appear in order. On ALL modern processors, this assumption is not true, it's possible for the write to location 3 to occur AFTER the read from location 3 on processor 2. It works great on single processor machines, but fails on MP machines.
In order to make the code work, you need to put a memoy write barrier after the write to location 3, this will force the write to be flushed from the cache.
If it could be shown that a significant change occurred in a species without a series of intervening mutations, that would falsify evolution.
Of course, the challenge would then be on the discoverer to propose an alternative that would also explain all of the things that evolution describes, and all the experimental evidence supporting it.
This HAS happened in the past. For instance, when Einstein proposed his Theory of Relativity, he threw out Newtons Theories of motion. But Einstein's theory was able to supercede Newtons theory by including all the existing experiments - Einstein's theory only becomes significant when your dealing with velocities close to the speed of light, and none of the previous experiments validating Newtons theories were executed close to that speed.
There is a huge volume of scientific evidence in favor of Evolution, just as there was a significant body of evidence in favor of Newtons theories of motion. Just like Newtons theories, it would be quite hard to falsify it, but it COULD happen.
Never said that NT hasn't had stuff from BSD before - it's well known that some of the TCP utilities in XP still have BSD copyrights on them.
But none of the items listed by the GP is evidence that the Vista kernel was rewritten based on BSD. All of the technologies cited have been in Windows for a very long time.
Man, I LOVE /. posters.
/. One of them describes a feature that's been in Windows since NT 3.1 (and exposed as a public API since Windows 2000) (symlinks). The other describes an existing feature that's been available for Windows since NT 4 and is now apparently being included in the OS base (SFU). And the third that describes a feature that's been available for Windows since NT 3.1 (and made really usable in XP) (limited rights user accounts).
:)
So you have three reports on
From these three technologies, all of which are over 10 years old, the poster decides that Microsoft rewrote the Vista OS based on BSD.
I love this forum
Anti-Virus doesn't help in the "connected to the internet for minutes" scenario. It helps in the "I downloaded this cool pr0n app from the internet" case.
Firewalls help in the "connected to the internet for minutes" case. And XP has one built in and enabled by default for well over a year now.
I'd like to see the "connected to the internet for minutes" numbers for XP SP2, to be honest.
Grr, hit submit too soon.
#2 above needs to read:
2) It would drive all software development to big companies (because they have enough cash on hand to cover the liability of their employees).
But what if the author of the defect is working on an open source project? And they're NOT employeed by a company? Who's held liable? Their employeer? The people who produced the distro?
What if they're a student at a university? Does the university have to accept liability?
Making the company that makes the product be liable for defects in the product would either do one of two things:
1) Drive all software development to be open source (because you're saying that individuals who contribute to open source projects will avoid all liability), or
2) It would drive all software development to big companies.
I'm with #2, because once you decide to adopt the idea that authors of software are held liable for their software's defects, there is NO WAY that they'd let a loophole as big as #1 exist - someone's got to be held responsible, and if there's no company to blame, they're got to find someone.
And the person who wrote the code that introduced the defect looks like a pretty good candidate to me.
Actually Word for the Mac has had PDF support for years.
My father's always been pissed at Microsoft for including PDF support in their Mac products but not in their PC products.
Do you have a reference to Microsoft stealing code from either DR or Stac?
/.
They were certainly found liable of infringing on Stac's patent, but I don't believe they were EVER shown to have stolen their CODE.
Similarly, do you have any references to Microsoft stealing Digital Research's code? Cloning their OS? Yes. But stealing their code?
Don't make accusations you can't back up with facts. Even on
Here's the thing. If the binaries had been digitally signed by the mozilla foundation, then the hacker's attempt to change the file would have broken the digital signature.
Without signatures on binaries, there's no way of knowing if the binary you download is the one that the author intended it to be.
This is so true - OSS is a force for commoditization. But you missed the corrolary to point.
Commodities aren't innovative. By their very nature, commodities can't be.
When was the last time you saw innovation in rice? How about innovation in breakfast cereal?
The key thing about a commodity is that they are 100% fungible. Each one is just as good as the next.
This totally precludes innovation - if it was innovative, it wouldn't be a commodity.
See the wikipedia definition of commodity for more info: http://en.wikipedia.org/wiki/Commodity
Excel? Nope, not purchased, 100% developed by Microsoft.
Now then, Powerpoint, Hotmail, Frontpage, etc were purchased.
But not Excel.
You can buy the office apps stand-alone.
For instance, here's Microsoft Word on Amazon.
Just because your local Best Buy doesn't stock it on the shelves doesn't mean it doesn't exist.
No, they can't. The changes in Microsoft's patches are reverse engineered. Exploits are written against a patch within 72 hours. Once the patch is released, you MUST deploy it or your are vulnerable to every bot author who wants to add your machine to their zombie army.
This is SO true. Zotob was reverse engineered and released only two or three days after the patch was released.
It seems to me that an Uzi's primary purpose is to make holes in things...