I'm working on getting an R/C car (with the R/C stuff removed) integrated with a sonar ring and a GPS. Currently the microcontroller is a 68HC11 (MIT 6.270 board), but I'm going to be switching to a mini-ITX board and a couple of PIC controllers connected via I2C. The basic idea for the bot is to let a user select a destination on campus (click on a map in a web page or something) and the robot will:
Use GPS to determine where it currently is
Do an A* Search to plan a path to the destination
Use GPS for navigation
Use sonar for obstacle avoidance
Negative obstacles are going to be a problem (i.e. holes in the ground , stairs, bottomless pits, etc).
This "NX" stuff to separate data and instructions is sort of like crossing current CPUs' Von Neumann architecture with a Harvard architecture type of chip, where the storage is actually separate from the executable code.
Actually the 386 in protected mode with segmentation is closer to a Harvard Architecture than what you get with the NX bit. Create 2 segments which split memory in two pieces. One is a code segment which is executable but not writeable, and the other is a data segment which is readable and writeable but not executable.
People, do yourselves a favor and read the Intel specs. Please? There is in fact, a bit for defining code segments.
Linux, Windows, BSD, etc. don't use segments, but instead use paging. Intel has dragged their feet on adding NX support because the feature "already exists", but the reality is that hardly anyone uses segments.
Ok, technically everyone uses segments -- they just create a single segment which covers all of the memory space. The GDT (Global Descriptor Table) must be configured when you switch to protected mode. Paging is optional.
The NX flag prevents a page (typically 4k) from executing. By marking all stack pages as NX, buffer overflow attacks won't be able to remotely execute arbitrary code. I assume that an exception will be generated when an attempt is made to execute from an NX page, which will probably cause the running program to halt. So, remote explots turn into DOS attacks.
Buffer overflow attacks have been known about for decades, and solutions such as NX have been known for quite some time too. As has been mentioned elsewhere on/., this does not remove the responsibility of developers to write good, secure code. But, as history has shown, they will probably continue with the long standing practice of writing insecure code.
NX will prevent buffer overflow attacks. NX will not be able to determine whether a program you choose to execute is good or evil. Viruses existed and managed to propogate back in the days before the Internet or even networking were in common use. NX won't solve all security problems, but it is a good tool to help reduce the possibility of remote exploits.
The NX flag isn't new, it's just new to the x86 world. Kudos to AMD for being the first to add this to the x86!
There are standard punishments for this type of behavior. To allow someone to build up this amount of debt is purely vindictive and would probably amount to a "cruel and unusual punishment". It seems to me, the department were only interested in collecting as much money from him as possible.
I thought he said that the University should have known, not that they did know that he had been cheating all along. In his argument for why he should shouldn't be kicked out, he is admitting that he has a history of cheating. A history of cheating is all the more reason why the University did the right thing.
Does anyone here realy believe that multiple professors would all be part of some conspiracy to milk this guy for all the money they could? That's what would have had to have happened -- a conspiracy. Multiple professors knew about the cheating, and either:
followed some written or unwritten University policy and turned a blind eye since he wasn't a senior yet
got together with his other professors and developed this conspiracy on their own without the blessing of the University
each professor came up with this scam independently
I would tend to believe that the University didn't catch him earlier because they hadn't been aware that he was cheating. That's far more believable than one of the options presented above. Also I would tend to belive an institution with a good reputation over a known liar and cheater...
Or, if he had been caught cheating before, his professors may have "taken it easy" on him and just failed him for their course. I know professors who have done that, but the problem with that approach is that a pattern of cheating is much harder to detect.
Incidentally, there is an easy way to avoid paying a high cost for the effects of viruses: don't let them infect your systems in the first place. And that's easy: keep them patched and up-to-date.
It isn't quite that easy. There have been exploits in the past which have been out before patches were available. To protect against that, you need to not be running the exploitable service. So, you should also run with as few services turned on as possible. Unfortunately, in Windows you can't turn most of them off without making your system unusable. So, you need a firewall. And you need to never execute downloaded code... and don't use Outlook or Internet Explorer... and don't run a software firewall which is one of the ones with security vulnerabilities...
A major problem with capital punishment for virus writers is that many viruses are written outside of the US. There are some countries who will not extradite criminals to the US if they will be facing the death penalty. I'm sure we can twist the Patriot Act around to allow our government to throw virus writers in jail without trial, and to allow the use of torture...
I have seen the implications. Finally I can start up my gas mining company, which will be run from my city in the clouds. Anyone know where I can pick up a good used carbonite chamber? I have this gut feeling that it will come in handy in the future...
Put in some real Samuel L. Jackson lines - "use the force, bitch", "can someone hand me my lightsaber -- it's the one that says Bad Ass M***********," "I shall strike down upon thee..." etc
Show some skin. Anikan should use force ass-grab, etc. Get creative with it (Darth-diggler anyone?)
Have Jar Jar in the back seat of a landspeeder and have Anikan accidentally shoot him in the face. Yeah, it's a blatant rip of but it still would be funny
Pamela Anderson - I don't care if she's part of the plot, or just there as scenery
I see a day coming when, in one day, half the computers in the US have their disks erased.
Everyone needs to go patch their systems immediately. We need to make sure that enough of us are around so that we can still slashdot the webserver that survives.
I have yet to see a single Microsoft patch for a theoretical security hole. It is routine with Open Source software to see a patch released to fix something that potentially could be a security risk. Often there's a suspicion by the developers that there is no actual way to exploit the issue, but they fix it just in case. Well written code is a matter of pride.
Microsoft, on the other hand, learns about remotely exploitable vulnerabilities and then takes 6 or 7 months to figure out how to fix it. Security researchers have to hound Microsoft to fix these things, despite the obvious severity of the holes.
Not all exploits are equal. If my box is only used by me, then local privilege elevation exploits are not an issue. Remotely exploitable holes in services I can't turn off are an issue.For many multi-user servers, local privilege elevation exploits are an issue. If your users are mostly trustworthy, then the remote execution holes are still worse.
MS04-11 Windows Local Security Authority Service Remote Buffer Overflow was reported to Microsoft on September 8, 2003 by eEye security.
MS04-12 Microsoft DCOM RPC Memory Leak and Race Condition was reported to Microsoft on September 10, 2003.
There still are 3 remote exploit holes which eEye identified which haven't been fixed. Two were reported 216 days ago, and the other was reported 188 days ago.
I really hope the author of the article isn't saying we should slow down beyond this. How do you know that any of these aren't zero-day exploits? Massive spreading worms are not the only security problem -- there are hackers who can find this stuff.
Pretend for a moment that you are a hacker who finds one of these holes. Do you want to waste the opportunity, giving it away to script kiddies, or use it to backdoor some of those systems you've been dying to get into. Script kiddies are the bane of your existance, because they force people into patching stuff that otherwise would be left wide open for you.
Now take the flip side of this. You're a sysadmin responsible for keeping a hacker like that out. Well, apparently you can't because companies are refusing to patch holes in a timely manner.
What will make it less secure is people using it without and idea of what they should be doing for security. Unless the average user can install it out of the box (they like boxes) and have all their security issues taken care of, they will most likley live with no security at all.
For the average joe user, a netstat should show that no processes are listening to the network. If you're not listening on any sockets, it's really, really hard to be remotely compromised.
So long as applications don't trust data which is coming from outside (i.e. email, and email attachments), the average user should be ok. If attachments can't be executed, it's pretty hard to spread email viruses. Sure, there are rare cases where it might be more convenient to have the atachment run automatically, but we all have seen where that approach gets you. Same thing with web browsers -- they should force the user to save an app (by default at least) rather than execute it for them.
Some form of secure auto-update is needed to keep these applications up to date. There will be holes in them which will eventually be discovered. The user shouldn't be involved (by default) in deciding whether or not to update.
Documents with embedded scripts that are run automatically are also asking for trouble. The average user receives a document and generally need to open it to see if it is legitimate or not.
The user should run with a non-privileged account. If (should that be when?) the user runs malicious code which slipped by all of these preventative measures, only the stuff they have access to is impacted.
If a system needs to be locked down more than this, it probably will negatively impact the usability of the system.
Waiting to patch until a working exploit has been released is not very wise. How do you know that there is no working exploit? Just because one hasn't been posted to bugtraq or elsewhere doesn't mean that it's not out there. I can understand ignoring DoS related security issues, but holes that allow the remote execution of code are really, really bad and should not be ignored.
What legitimate need do you have to leave a hole? That makes no sense to me at all. That's like saying "we need the DCOM RPC hole because we developed a remote management utility which deploys software via that hole". That's all well and good if you created such a program, but it's a lousy reason to allow anyone on the Internet to run code on your box. Am I missing something here? Or are you talking about using protocols with known security weaknesses? That's another matter entirely.
Is the question, "should tools exist which allow system administrators to scan their boxes for known holes?" That's an easy one to answer: YES.
A quick glance through my log files shows that someone is scanning my boxes. Not distributing scanning tools just makes it a one sided battle (with us admins on the loosing side). Not knowing about a hole does not mean that the hole doesn't exist. So, I think that it's far better to make a level playing field, and let hackers and admins have equal opporunity for knowing the status of a box. Sure, some people won't check their systems, but that's a lost cause no matter what.
Microsoft recently said something along the lines of the security problem being partly due to many users being unwilling to [shell out money to] upgrade to the newest version of their OS. So which is it? Is Microsoft for security or against it? I'm confused.
1) WMP won't run on the Mac. That's by Microsoft's choice, so it's not really an option.
2) iTunes, on the other hand, will run on Windows.
Aside from that, Microsoft is a monopoly. They were found guilty of using their position in the desktop marketplace to destroy competition. Apple is the one who innovated buying music online, not Microsoft. Microsoft wants to, yet again, steal someone else's idea and then leverage their monopoly position to ensure that they beat out all of the competition.
How is this any different than IE vs Netscape? When Netscape came out, Microsoft didn't want to have a thing to do with the Internet. Then, when they put their minds to it they were able to destroy the competition (again, that monopoly thing). Microsoft didn't want anything to do with online music stores until they saw how much money they could make.
Hopefully Apple ask for an injunction against Microsoft, and force them to either delay shipping Longhorn and XP part II while the legal stuff plays out, or force them to ship with an iTunes client.
I seem to recall Microsoft touting Windows XP as the most secure [Microsoft] OS ever. Why would anoyone possibly believe thim this time around? We've heard the same thing over, and over from them: "we take security seriously now." So when exactly are they going to start?
This security stuff is still just Marketing and PR speak. It's simply a way to try to force the masses to shell out lots of cash to buy their latest bloatware, and to make suits feel like Microsoft is working to improve security.
They wanted the next version of Office to only work on Longhorn. Hmm, that sounds like just one more tactic to force people to shell out cash to buy their latest OS. They've kept incompatibility as a club for their sales staff to beat users with, and have now added security hype as another big stick.
OS X - 1 trojan every 3 years is a track record I can live with.
Out of curiousity, what happens if the power goes out during an election? Are these machines on UPSes? Are their power down procedures which ensure that note votes are lost?
Does anybody know of a case where someone has been attacked through a Microsoft vulnerability between the time of its going public and the release of the patch? The most often encountered scenario seems to be people who never upgrade getting attacked because hackers have reverse engineered the patches.
I think it was Stanford University that got hit with some of the RPC DCOM vulnerabilities before a patch was released. No, it wasn't one of the worms, it was hackers backdooring systems.
Microsoft has 2 critical vulnerabilities which they have known about for 209 days. Another one they've know about for 182 days. I don't know of any open source security holes which have sat for 209 days!
I don't buy for a minute that 1) Microsoft releases patches faster or 2) that Microsoft even gives a damn about security, except for the black eye it gives them.
Hard Drives have always been one of the slowest components in a system. There are many applications for which this is not a big deal -- once loaded, the app is CPU or memory bound. A lot of applications are bound by the limits on memory, which can be helped out by caching, and/or faster memory. Faster memory is achieved through improved semiconductor fabrication processes.
If you require a storage system which can handle 150MB/s, it's entirely feasible. RAID uses multiple independent disks to acheive higher performance (as well as provide data redundancy). A good RAID controller and lots of 15k RMP SCSI drives will get you to your goal.
By my math, your argument of the hard drive (one with a 150MB/s transfer rate) being the big bottleneck means that the P4 only needs about a 20 MHz Front Side bus instead of 400, 533 or 800 MHz. So, a 25 MHz 386 should provide the maximum performance you'll see in any of your applications... Clearly that's not the case, so I don't think it's fair to say that CPU speed improvements are worthless until hard drive performance improves.
Microsoft is very much to blame for a lot of the security problems which exist today. They continue to treat security issues as a PR problem rather than the security/technical issues they really are. If they truely were concerned about security, they would address security holes in a timely manner. See eEye Digital Security's Upcoming advisories for proof. If Microsoft were truely serious, these holes would have been patched months ago.
Microsoft, until recently, refused to listen to security experts who reccomend that OSes ship with services turned off by default. They have started to move in the right direction, with server 2003, but they are not there yet.
The Microsoft model essentially requires users to run as Administrator. Many 3rd party applications make the assumption that the user is Administrator, and won't run properly in a less privileged account. Microsoft has even made some apps which have the same requirements.
Microsoft's software is very layered, with many higher level functions relying on lower level layers. Outlook, and its relationship to to Internet Explorer is a good example. Bugs in IE (and you know there are lots of them) are frequently exploited by email worms. The time and effort just have not been put in by Microsoft to ensure that the lower layers of their architecture are secure. If the foundation is full of holes, there's no way to secure what's built on top.
OS X is a very good example of how to do security correctly. Users run as regular users, rather than as a privileged account. Some users are allowed to execute commands as root, via a sudo like mechanism (or using sudo from the command line), but it's an explicit step which must be taken by the user.
The notion that Apple is just for ignorent users is just absurd.
Hardware protection of page table entries has been available on many other CPUs for a long time. Intel actually supports a similar thing - non-executable segments, but it's difficult to write an efficient multitasking OS which is segment based. I think BSD uses some sort of segment protection trick to achieve the protection you're talking about (I'm not an OpenBSD expert though so I'm not positive).
Buffer overflows attacks are best prevented by proper programming to begin with. That "solution" has been known for 20-30 years now, yet the problem persists. Obviously it's not sufficient. Another thing which helps is to load code into different locations in memory every time a program is loaded (ala RedHat's PIE). Hardware protection is effective, and adds an additional layer of security. Page table protection like this is already supported in Linux on platforms which support it (including AMD-x86-64).
Intel should be condemned for resisting on this particular issue. This is a case where they are hindering efforts to improve security. This is NOT Palladium type hardware "protection". Arguing against this feature is like arguing that home users should rely on Microsoft's firewall technology instead of a hardware firewall.
Go check Groklaw. IBM is asking for a declaratory judgement. SCOX trading tomorrow should be, um, amusing.
Just keep in mind that "declaratory judgement" != "summary judgement". IBM is asking for a declaration that it is not violating any of SCO's copyrights.
Such a judgement would be a huge win, but it won't be the end of the case. It also wouldn't end the other lawsuits SCO has, because those realy aren't Linux lawsuits, despite what SCO would have you believe (ok, Linux is a component of the AutoZone case).
As for what their stock will do, who knows. It will probably go up. It has a target price of $45.00 after all, and you know those analyists have your best interests in mind...
Slashdot Mirror
- Use GPS to determine where it currently is
- Do an A* Search to plan a path to the destination
- Use GPS for navigation
- Use sonar for obstacle avoidance
Negative obstacles are going to be a problem (i.e. holes in the ground , stairs, bottomless pits, etc).Actually the 386 in protected mode with segmentation is closer to a Harvard Architecture than what you get with the NX bit. Create 2 segments which split memory in two pieces. One is a code segment which is executable but not writeable, and the other is a data segment which is readable and writeable but not executable.
Linux, Windows, BSD, etc. don't use segments, but instead use paging. Intel has dragged their feet on adding NX support because the feature "already exists", but the reality is that hardly anyone uses segments.
Ok, technically everyone uses segments -- they just create a single segment which covers all of the memory space. The GDT (Global Descriptor Table) must be configured when you switch to protected mode. Paging is optional.
The NX flag prevents a page (typically 4k) from executing. By marking all stack pages as NX, buffer overflow attacks won't be able to remotely execute arbitrary code. I assume that an exception will be generated when an attempt is made to execute from an NX page, which will probably cause the running program to halt. So, remote explots turn into DOS attacks.
Buffer overflow attacks have been known about for decades, and solutions such as NX have been known for quite some time too. As has been mentioned elsewhere on /., this does not remove the responsibility of developers to write good, secure code. But, as history has shown, they will probably continue with the long standing practice of writing insecure code.
NX will prevent buffer overflow attacks. NX will not be able to determine whether a program you choose to execute is good or evil. Viruses existed and managed to propogate back in the days before the Internet or even networking were in common use. NX won't solve all security problems, but it is a good tool to help reduce the possibility of remote exploits.
The NX flag isn't new, it's just new to the x86 world. Kudos to AMD for being the first to add this to the x86!
I thought he said that the University should have known, not that they did know that he had been cheating all along. In his argument for why he should shouldn't be kicked out, he is admitting that he has a history of cheating. A history of cheating is all the more reason why the University did the right thing.
Does anyone here realy believe that multiple professors would all be part of some conspiracy to milk this guy for all the money they could? That's what would have had to have happened -- a conspiracy. Multiple professors knew about the cheating, and either:
- followed some written or unwritten University policy and turned a blind eye since he wasn't a senior yet
- got together with his other professors and developed this conspiracy on their own without the blessing of the University
- each professor came up with this scam independently
I would tend to believe that the University didn't catch him earlier because they hadn't been aware that he was cheating. That's far more believable than one of the options presented above. Also I would tend to belive an institution with a good reputation over a known liar and cheater...Or, if he had been caught cheating before, his professors may have "taken it easy" on him and just failed him for their course. I know professors who have done that, but the problem with that approach is that a pattern of cheating is much harder to detect.
It isn't quite that easy. There have been exploits in the past which have been out before patches were available. To protect against that, you need to not be running the exploitable service. So, you should also run with as few services turned on as possible. Unfortunately, in Windows you can't turn most of them off without making your system unusable. So, you need a firewall. And you need to never execute downloaded code... and don't use Outlook or Internet Explorer... and don't run a software firewall which is one of the ones with security vulnerabilities...
A major problem with capital punishment for virus writers is that many viruses are written outside of the US. There are some countries who will not extradite criminals to the US if they will be facing the death penalty. I'm sure we can twist the Patriot Act around to allow our government to throw virus writers in jail without trial, and to allow the use of torture...
I have seen the implications. Finally I can start up my gas mining company, which will be run from my city in the clouds. Anyone know where I can pick up a good used carbonite chamber? I have this gut feeling that it will come in handy in the future...
Everyone needs to go patch their systems immediately. We need to make sure that enough of us are around so that we can still slashdot the webserver that survives.
Microsoft, on the other hand, learns about remotely exploitable vulnerabilities and then takes 6 or 7 months to figure out how to fix it. Security researchers have to hound Microsoft to fix these things, despite the obvious severity of the holes.
Not all exploits are equal. If my box is only used by me, then local privilege elevation exploits are not an issue. Remotely exploitable holes in services I can't turn off are an issue.For many multi-user servers, local privilege elevation exploits are an issue. If your users are mostly trustworthy, then the remote execution holes are still worse.
MS04-12 Microsoft DCOM RPC Memory Leak and Race Condition was reported to Microsoft on September 10, 2003.
There still are 3 remote exploit holes which eEye identified which haven't been fixed. Two were reported 216 days ago, and the other was reported 188 days ago.
I really hope the author of the article isn't saying we should slow down beyond this. How do you know that any of these aren't zero-day exploits? Massive spreading worms are not the only security problem -- there are hackers who can find this stuff.
Pretend for a moment that you are a hacker who finds one of these holes. Do you want to waste the opportunity, giving it away to script kiddies, or use it to backdoor some of those systems you've been dying to get into. Script kiddies are the bane of your existance, because they force people into patching stuff that otherwise would be left wide open for you.
Now take the flip side of this. You're a sysadmin responsible for keeping a hacker like that out. Well, apparently you can't because companies are refusing to patch holes in a timely manner.
For the average joe user, a netstat should show that no processes are listening to the network. If you're not listening on any sockets, it's really, really hard to be remotely compromised.
So long as applications don't trust data which is coming from outside (i.e. email, and email attachments), the average user should be ok. If attachments can't be executed, it's pretty hard to spread email viruses. Sure, there are rare cases where it might be more convenient to have the atachment run automatically, but we all have seen where that approach gets you. Same thing with web browsers -- they should force the user to save an app (by default at least) rather than execute it for them.
Some form of secure auto-update is needed to keep these applications up to date. There will be holes in them which will eventually be discovered. The user shouldn't be involved (by default) in deciding whether or not to update.
Documents with embedded scripts that are run automatically are also asking for trouble. The average user receives a document and generally need to open it to see if it is legitimate or not.
The user should run with a non-privileged account. If (should that be when?) the user runs malicious code which slipped by all of these preventative measures, only the stuff they have access to is impacted.
If a system needs to be locked down more than this, it probably will negatively impact the usability of the system.
What legitimate need do you have to leave a hole? That makes no sense to me at all. That's like saying "we need the DCOM RPC hole because we developed a remote management utility which deploys software via that hole". That's all well and good if you created such a program, but it's a lousy reason to allow anyone on the Internet to run code on your box. Am I missing something here? Or are you talking about using protocols with known security weaknesses? That's another matter entirely.
A quick glance through my log files shows that someone is scanning my boxes. Not distributing scanning tools just makes it a one sided battle (with us admins on the loosing side). Not knowing about a hole does not mean that the hole doesn't exist. So, I think that it's far better to make a level playing field, and let hackers and admins have equal opporunity for knowing the status of a box. Sure, some people won't check their systems, but that's a lost cause no matter what.
Microsoft recently said something along the lines of the security problem being partly due to many users being unwilling to [shell out money to] upgrade to the newest version of their OS. So which is it? Is Microsoft for security or against it? I'm confused.
They're only 133. Says so right in the article.
1) WMP won't run on the Mac. That's by Microsoft's choice, so it's not really an option.
2) iTunes, on the other hand, will run on Windows.
Aside from that, Microsoft is a monopoly. They were found guilty of using their position in the desktop marketplace to destroy competition. Apple is the one who innovated buying music online, not Microsoft. Microsoft wants to, yet again, steal someone else's idea and then leverage their monopoly position to ensure that they beat out all of the competition.
How is this any different than IE vs Netscape? When Netscape came out, Microsoft didn't want to have a thing to do with the Internet. Then, when they put their minds to it they were able to destroy the competition (again, that monopoly thing). Microsoft didn't want anything to do with online music stores until they saw how much money they could make.
Hopefully Apple ask for an injunction against Microsoft, and force them to either delay shipping Longhorn and XP part II while the legal stuff plays out, or force them to ship with an iTunes client.
This security stuff is still just Marketing and PR speak. It's simply a way to try to force the masses to shell out lots of cash to buy their latest bloatware, and to make suits feel like Microsoft is working to improve security.
They wanted the next version of Office to only work on Longhorn. Hmm, that sounds like just one more tactic to force people to shell out cash to buy their latest OS. They've kept incompatibility as a club for their sales staff to beat users with, and have now added security hype as another big stick.
OS X - 1 trojan every 3 years is a track record I can live with.
Out of curiousity, what happens if the power goes out during an election? Are these machines on UPSes? Are their power down procedures which ensure that note votes are lost?
I think it was Stanford University that got hit with some of the RPC DCOM vulnerabilities before a patch was released. No, it wasn't one of the worms, it was hackers backdooring systems.
reference
I don't buy for a minute that 1) Microsoft releases patches faster or 2) that Microsoft even gives a damn about security, except for the black eye it gives them.
If you require a storage system which can handle 150MB/s, it's entirely feasible. RAID uses multiple independent disks to acheive higher performance (as well as provide data redundancy). A good RAID controller and lots of 15k RMP SCSI drives will get you to your goal.
By my math, your argument of the hard drive (one with a 150MB/s transfer rate) being the big bottleneck means that the P4 only needs about a 20 MHz Front Side bus instead of 400, 533 or 800 MHz. So, a 25 MHz 386 should provide the maximum performance you'll see in any of your applications... Clearly that's not the case, so I don't think it's fair to say that CPU speed improvements are worthless until hard drive performance improves.
I use my middle finger. Is there another way to do it? =)
Microsoft, until recently, refused to listen to security experts who reccomend that OSes ship with services turned off by default. They have started to move in the right direction, with server 2003, but they are not there yet.
The Microsoft model essentially requires users to run as Administrator. Many 3rd party applications make the assumption that the user is Administrator, and won't run properly in a less privileged account. Microsoft has even made some apps which have the same requirements.
Microsoft's software is very layered, with many higher level functions relying on lower level layers. Outlook, and its relationship to to Internet Explorer is a good example. Bugs in IE (and you know there are lots of them) are frequently exploited by email worms. The time and effort just have not been put in by Microsoft to ensure that the lower layers of their architecture are secure. If the foundation is full of holes, there's no way to secure what's built on top.
OS X is a very good example of how to do security correctly. Users run as regular users, rather than as a privileged account. Some users are allowed to execute commands as root, via a sudo like mechanism (or using sudo from the command line), but it's an explicit step which must be taken by the user.
The notion that Apple is just for ignorent users is just absurd.
Hardware protection of page table entries has been available on many other CPUs for a long time. Intel actually supports a similar thing - non-executable segments, but it's difficult to write an efficient multitasking OS which is segment based. I think BSD uses some sort of segment protection trick to achieve the protection you're talking about (I'm not an OpenBSD expert though so I'm not positive).
Buffer overflows attacks are best prevented by proper programming to begin with. That "solution" has been known for 20-30 years now, yet the problem persists. Obviously it's not sufficient. Another thing which helps is to load code into different locations in memory every time a program is loaded (ala RedHat's PIE). Hardware protection is effective, and adds an additional layer of security. Page table protection like this is already supported in Linux on platforms which support it (including AMD-x86-64).
Intel should be condemned for resisting on this particular issue. This is a case where they are hindering efforts to improve security. This is NOT Palladium type hardware "protection". Arguing against this feature is like arguing that home users should rely on Microsoft's firewall technology instead of a hardware firewall.
Just keep in mind that "declaratory judgement" != "summary judgement". IBM is asking for a declaration that it is not violating any of SCO's copyrights.
Such a judgement would be a huge win, but it won't be the end of the case. It also wouldn't end the other lawsuits SCO has, because those realy aren't Linux lawsuits, despite what SCO would have you believe (ok, Linux is a component of the AutoZone case).
As for what their stock will do, who knows. It will probably go up. It has a target price of $45.00 after all, and you know those analyists have your best interests in mind...