Windows Vista still Rife with Insecure Code 330
osxpetition writes "As noted in a News.com article, Symantec researchers have been testing the latest Microsoft Windows Vista build (Beta 2), and have found that the code is 'complete with new corner cases and defects' in the networking component. Symantec describes how Microsoft scrapped the old networking stack code from Windows XP in favour of newer, rewritten code. 'Microsoft has removed a large body of tried and tested code and replaced it with freshly written code.' Since January 2002, Microsoft has put a stronger emphasis on protecting PCs by attempting to implement stable, secure code into Windows XP and their new operating system. This latest report from Symantec brings attention to Microsoft's trustworthy computing campaign, and shows how it will be a long way before it is ready for the mainstream."
Re:I would like to know (Score:2, Interesting)
Are any of those running as privileged, or communicating with the system services in an unsafe manner?
Re:Mistake? (Score:3, Interesting)
Crackers will become familiar with Vista's net stack soon or later, either by reverse-engineering the new not-so-secure stack, or by utilizing their familiarity with the XP stack (in case MS didn't replace it), it's a cat and mouse game, just like how they found exploits in the first one, they will find ones in Vista's stack, the solution is to write a secure networking stack, not to replace it with another vulnerable one that hasn't been reverse-engineered yet.
Re:You joke, but (Score:3, Interesting)
Considering that they even have legislation to require wiretappable telecom infrastructure, I wouldn't be surprised.
In fact, I think it's the only way to explain how many security bugs are in Windows. Don't buy the excuse of it taking a lot of resources -- Microsoft has a *LOT* of resources including billions of dollars in the bank; and the OpenBSD group have a near perfect track record with a better performing OS with a budget thousands of times smaller than what Microsoft pays as dividends to shareholders.
If they wanted to fix their security problems, they could and OpenBSD is proof of that. The fact that instead they pay out dividents to shareholders (which is what a company does when it can't think of a better use for the money) means that they have some reason not to want to fix the problems.
Clearly it's not a marketing decision - it's bad press every time another one of these backdoors is exposed -- and it's not a feature corporate customeres want -- so it most likely is a policy decision with governments.
Re:I would like to know (Score:4, Interesting)
The security model is built on "window stations" -- If you put a privileged window into an unprivileged window station, then you have made a configuration error. Period.
The author of the paper stated that *nix/X11 is just as vulnerable to these types of attacks, BTW, so *nix is just as irrevocably mis-designed as Windows. The only difference is that *nix programmers are smart enough not to write interactive software that runs as root.
Re:I would like to know (Score:5, Interesting)
This was a design decision with known trade-offs. Attaching security tokens to window messages would result in MAJOR overhead that would, even on today's beefy hardware, kill performance. Having to do a permissions check every time the mouse is moved is not feasible.
So Microsoft decided that they would rely on "best practices" information as apposed to enforced security in the OS to prevent "shatter attacks". The best practices are pretty simple: If your service/application is running with elevated permissions (such as SYSTEM), do not display a GUI on a desktop owned by a lower privledged user.
There have been examples of applications, in particular some poorly written anti-virus applications, that liked to display GUIs to the user despite the fact they were running as SYSTEM. For the most part, however, very few major applications exist today that have this issue.
Applications that run with high privs that need to display a GUI typically launch their GUI with the privs of the user, or display the GUI on a secure desktop. (Like Winlogon.exe.)
This is really a non-issue and hasn't been for a very long time. Please, ignore the FUD.
Well, no it isn't. (Score:3, Interesting)
It should be very easy to build a networking stack for Windows (or any other OS) that is bullet-proof, compact and fast, because it's not a particularly complex piece of logic. There are lots of rules, sure, but each rule within itself is very simple. That makes it possible to test each decsion-making component directly and individually, along with the rule that component applies. Because you know what a well-formed packet looks like - that is defined by the applicable RFC(s) - you can also do comprehensive bottom-up integrated testing.
Add in one of the multitude of profiling packages that will work with kernel-level code, and it should be child's play to make the code not only correct but damn fast.
Could Microsoft do this? Of course they could. They might act the part, but that doesn't make them idiots. In general, anyway. How long it would take and how much manpower it would take depends on how correct they'd want the code. If you want to guarantee fewer than N errors per M lines of code, you can do it, but halving N will more than double the effort required. Can you guarantee no errors at all? Yes. The networking stack is simple enough that you can prove it complete, sufficient and correct. It would cost Microsoft far less to prove their network stack totally bug-free than they're owing the EU in fines. Personally, I feel that producing better code would have been a wiser investment, but that's their decision to make.
could Linux developers do this? Again, sure. There are many tools for profiling and analyzing the Linux networking stack, and suitable test harnesses shouldn't be that hard to write. If kernel hackers had more of a liking for testing, Linux networking bugs should be all but extinct within a year. As things stand, the cleanup is OK but not enough to seriously endanger the bug population. I would like to see a concerted effort to clean up the code rigorously, but I do recognize that much of the code is "good enough" for most developers to be more interested in expanding the capabilities than polishing the code to perfection.
Re:You joke, but (Score:5, Interesting)
In fact, I think it's the only way to explain how many security bugs are in Windows.
I think you perhaps need to take some lessons in critical thinking. This is the equivelent of saying, "The only reason auto-manufactuers put problems into cars so they have to recall them is because the government makes them, which is why Japanese cars are better than American cars."
Large monolithioc systems are inherently more complex that smaller componant built systems. (Although those have problems too along the boundary interfaces.) Auto-makers put lots of time and money into making a car that A) doesn't fall apart and B) doesn't require a multi-billion dollar recall effort. Microsoft puts lots of time and money into trying to make their software more secure.
On the whole, I'd say the auto companies do a better job. :-) Thowing money at a problem very rarely solves the problem. The need to have an understanding of the problem, and how to fix the underlying problem is vital. I think that is where Microsoft fails. The systems they have in place (from what I hear) are more frustrating to the engineers than helpful.
I also have problems believing MS engineers are really motivated these days. Many of Microsoft's security issues have stemmed from their own code interactions which they implemented as deliberate features. Many more have been from sloppy programming (such as buffer overruns).
Trying to blame MS security issues on government mandated back doors smacks of plain political diatribe with a nice glossy veneer of ignorance on the top to give it a nice sheen.
It's part of the bigger picture (Score:4, Interesting)
Re:I would like to know (Score:3, Interesting)
But you have to remember that the only way that dialog will affect the entire system is if the user is running as admin, and if the user is running as admin the malware likely is to... so they don't really have to simulate clicks to do their damage.
Re:Fun-factor (Score:4, Interesting)
From the October 2000 MSDN magazine, "Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports" [microsoft.com] Ironically, it's TDI that's being replaced for something more sockets-like.
I think this is yet another example of Microsoft not understanding code that was previously written by someone no longer available, causing the new developers to misunderstand the original design, who then feel the only option is a rewrite. I've yet to hear any technical comparisons between TDI and "Next Generation TCP/IP", showing how the TDI architecture could never do those things. I bet TDI can support these new features with some new code, but it just wouldn't be as glamorus that way.
To adapt an old saying about LISP and UNIX, "Those who fail to understand NT are doomed to reimplement it. Poorly"
Re:It has been fixed (Score:3, Interesting)
You can exploit a buffer overflow by changing the name of the stupid "Start" button! There are PLENTY of MS applications on XP that are vulnerable to this attack.
Re:I would like to know (Score:3, Interesting)
The application I do this to does provide an API for remote control, but they left out some obvious things. They are not going to add them in, so I take control of their window. Works a treat.
Point is, its not a design flaw. Its damn useful.
However it should be secured in some way - so as a suggestion, have the OS pop up a window: "app A is trying to send messages to or control app B, is this ok? (Generally its a bad idea)"
Default to no.
Re:However (Score:3, Interesting)
Yes, yes. Cruddy and Complex code is cruddy and complex because it needs to be cruddy and complex (not because it was hacked together on an impossibly short schedule, or written by a novice developer using a fundamentally bad design. Or both.) And you should never rewrite code. Ever (except when you should).
There are no absolute rules in software engineering. Part of the art of the game is knowing when to toss code that is so impossibly bloated that it would take many times longer to "re-factor" than to "re-write." And despite the fact that many (most?) people are bad at making this decision, it is not automatically true that code should never be re-written.
Re:beta (Score:3, Interesting)
I think what I have gotten out of this is the whole is a damned if they do/damned if they don't issue taken with Microsoft. Before this article came out, people blasted MS for the fact that they had such bloated and bad code. Now that MS is in the practice of trying to replace all this "bloated" code, but are now being attacked on the front that they have untested code.
IMHO, this was something that was going to come regardless of what MS choose to do. Eventually, they were going to have to get their code (be it network, kernel, etc) out of the code base and move to new code, or suffer from really bloated code that was years old.
I think this is where the whole being Beta and their Beta program comes in. So long as they have these issues fixed BEFORE their commercial software is out, I think MS is fine. Now, if they let Vista go and it still has a bulk of untested code, then there are problems. (And I get that the article does point this out in a a single paragraph, but the point is, if CNET really thought about this, then you might think they would have realized maybe the article shouldn't have been written).
RonB
Sounds to me like... (Score:2, Interesting)
"However, these were all fixed by Microsoft in build 5384, the version of the operating system that was publicly released in May as Beta 2."
That's not to say the code is totally secure but that that seems to be a very good sign.
Don't forget to question your sources. If I was Symantec, I would be worried that in the case that Windows Vista is secure, and does come with a good build in antivirus that my revenue would go down the drain. For those of you who have ever used recent versions of Norton Antivirus or Internet Security, you know what I'm talking about. The widely used Norton software is honestly rather bloated and probably presents a security risk of its own. As an IT technician, I get a lot of requests from workers to remove Norton because Norton causes an alarming measurable slowdown in system performance.
Given that all the bugs found by Symantec were fixed in build 5384 and the fact that Vista still has about 5-6 months before it goes gold (at the earliest), any attempts to speculate on the security of Vista is just that -- pure speculation.
Re:beta (Score:2, Interesting)