"Security works best when it's designed into the system from the beginning, so a lot of what they've already done is going to have to be rewritten."
This is false. XP, based on NT, has security built in. The vulnerabilities discovered so far basically seem to be in two camps:
1) Buffer overflows left in the code -- rewriting won't help these, it will likely just introduce more. They just need to be found and fixed. Microsoft is in fact going over all its code line-by-line, but I can't imagine that glassy-eyed developers spending a month doing that is actually going to find all the overflows.
2) Bad design, in particular allowing foreign code to execute. I.e. the various Outlook email viruses. These need to be removed, which is a basic change in how Microsoft thinks (security over nifty features) but again you don't need to rewrite Outlook to stop if from executing scripts by default.
Methinks Schneier might be fantasizing a bit about Microsoft *having* to do this, of saying, as he puts it, "We're going to put the entire.NET initiative on hold, probably for years, while we work the security problems out." It seems like he would like to see Microsoft fall behind in the market because they have to throw all their current code away. Plus he hates SOAP (since it sneaks past firewalls inside HTTP), which is one of the technologies.NET is based on.
Personally I think this is basically more marketing hype from Microsoft. Because they are still not going to penalize developers who write insecure code (something that was bandied about but not adopted) -- it will still be, "Oops, we did it again". So with no real connection between good code and stock options, developers at Microsoft won't change.
IM-ever-so-HO, this article is focussed on the compiler and runtime and misses the point. It would be like talking about Win32 in terms of the format of DLLs and how the compiler links against export libraries.
The "web services" (or whatever you call them -- API calls over the net) are the reason for.NET.
The sentence in DrPizza's article:
".NET is also the collective name given to various bits of software built upon the.NET platform. These will be both products (Visual Studio.NET and Windows.NET Server, for instance) and services (like Passport, HailStorm, and so on)."
is misleading. Visual Studio and Server are not built on.NET, one is a dev environment and one is an operating system. Hailstorm is a ".NET application" and that type of application is the reason for.NET.
I could be wrong of course. Maybe.NET will turn out to be just a new runtime model...which seems a big waste of an opportunity. The only real advance I can see is that it gives Microsoft a chance to redo all their libraries so they do security checks...which is very topical, but doesn't seem worthy of all the hype about.NET
and best of luck in the future, to both of you, and to any CmdrTaquitos that come along.
- adam
What .NET is...
on
What is .NET?
·
· Score: 3, Interesting
Throughout its history, Microsoft has defined three platforms for application developers: DOS, Win16, and Win32. You could argue that COM is a separate platform or an extension of Win32, but the basic idea is the same. At every stage of the development of the personal computer, software developers have asked, "How do I write an application?"
And Microsoft has provided the answer: Here is the runtime model, here are the APIs you call, here are some tools you can use, here is how to get help if you have problems.
Now substitute a web of connected personal computers -- the Internet -- for a single one, and developers are still asking, "How do I write an application?" And Microsoft's answer is,.NET.
DOS provided very few services to application writers, but with the Windows APIs, things got more sophisticated: support for graphics, for printing, for various other input and output devices, and eventually for networking. These were filtered through a standard Microsoft-provided operating system to various third-party devices, each with their own device driver, which performed the actual work.
In the.NET world, the "API" will handle Internet-related issues such as password verification, price calculation, payment, and so on. The "operating system" will be a set of always-available Web sites that may then dispatch the actual work to third-party sites -- the "device drivers" in the.NET model.
That is an excerpt from a
longer article which I wrote back in November 2000.
is actually 29.97 frames/second, that is exactly 0.1% less than 30 fps. Actually it technically runs at 59.94 half-frames per second. Anyway, when you convert a movie for TV you take it from 24 frames per second to 60 half-frames per second, then you have to lose 0.1% of the frames to get it down to the proper speed. This is considered unnoticeable and there is a standard for which ones to axe (in an hour, with 108,000 frames, you need to get rid of 108. The convention used is to get rid of the first two frames of every minute that is not a multiple of ten). But this device here is trying to lose more than 16 times as many frames, even to only cut out 30 seconds in 30 minutes. That might be noticed.
And am I simply naive, or is there something profoundly disturbing about such shenanigans going on even as District Court Judge Colleen Kollar-Kotelly allegedly mulls the proper punishment of the Microsoft Corporation, an illegal monopoly, for violating U.S. antitrust law?
You're simply naive. Last time I checked advertising was legal, even for Microsoft.
Katz may indeed specialize in imperious intonation (although where I used to disagree with about 95% of what he wrote, I now agree with about 95% -- a frightening thought). But here is why Katz's slashdot writing is not a blog:
1) He is not self-publishing, since technically what he writes has to be approved by the slashdot crew. Now I don't know if they actually reject anything he writes (any more than Newsweek ever rejects something by one of their regular columnists once they have established cred), but still it is different than a blog.
2) It is not on a site devoted exclusively to him. As a result, there is a lot of discussion about what he writes because the site has people who are both for and against what he writes (due to all the other content). On a blog, people who disagree with the person's viewpoints tend not to read the blog at all, so the discussion is very one-sided if it exists at all.
3) On the downside, Katz (as far as I know) does not participate in the debate about his writings, but merely floats above it all. This is also un-blog-like, although arguably not an improvement.
- adam
blogging and the death of the commons
on
Browsing Alone
·
· Score: 4, Insightful
I feel that blogging, which its proponents claim increases communication, is actually a negative. Unlike discussion groups like slashdot where community actually forms and issues are debated back and forth (between the trolls), a blog is just one person shouting out. "Discussions" between bloggers are rare and usually involve one of the two parties simply dropping the issue after a few exchanges.
Furthermore, bloggers get "pundit syndrome" where because their views are "published", they feel they know more than others, thus reinforcing their tendency to intone imperiously rather than enter into debates. This further destroys any chance for a community to form, unless you count a swarm of boot-licking toadies congregating around one blog to be a community.
If you read the link I included to osopinion, you will see that I worked as a developer on Windows 2000 for Microsoft, and was involved in the security cleanup of the code for Windows XP.
Anyway the core code is written in C and will stay that way. XP undoubtedly is the most secure OS they have released, but you have things like the UPNP exploit slip through. Not part of the main code, probably written by some college new hire, and no doubt checked in *after* the big security sweep was done (which was just when Windows 2000 shipped). Still that is the only exploit I have heard of in XP so far (excluding Outlook and IIS ones) and may in fact wind up being the only one, because most of the code *was* scrubbed pretty hard.
But to really drive it home you have to tie it to salary/bonus/option grants because that is the real way people are measured at Microsoft.
This part of the article made me laugh:
One person with knowledge of the change said new products and features will be tested for security risks before going any further -- if they fail, the feature won't be included. "Things are going to have to go through a crucible, and the crucible will be security-first," according to this person, who spoke only on condition of anonymity.
Yeah right. What crucible. A buffer overflow is not something a"security review" is going to find. You just have to write the code carefully.
Compensation plans of Microsoft product engineers, such as raises and bonuses, will also be tied to how secure their products are.
This gives hope however. Reviews at Microsoft are always just about the last six months, so nobody was ever dinged for a bug that turned up a year after they shipped. But now maybe that will happen.
OO as a way of thinking can be done in any language. What an OO *language* can offer is really two things that C can't, recovery of the "this" pointer and late binding.
Recovery of the "this" pointer means that any function will magically have a pointer to the object it is working on available. Now normally this doesn't matter much because you can just have the function take itself as an argument (or a magically cast-to-void "handle" if you want to be opaque about it). But when you start to have inheritance, it can be tricky for the calling function to figure out what pointer to use. The OO language will do this for you.
Late binding means you can link at runtime, not compile time. C++ offers this recovery but not late binding. Java and COM offer both.
The rest is mostly OO hype. The big argument about how you can encapsulate everything inside a function is bogus because then you just convert it into a documentation issue, of knowing what exact random thing the designer of the function has decided it is appropriate to do. This is no different in OO or non-OO.
The best, really the only successful realization of the OO dream of small interconnectable pieces so far is the Unix command line tools with pipes between them. Sure the data exchange format is trivial and limited, but the system actually works, and users can easily join together small reusable pieces of code to accomplish (most of) what they desire. The fact that this system is 30 years old and has not been improved upon just shows that <insert cliche here>.
Ah yes, the ubiquitous fart joke...it's funny, the Pixar movies (Bugs Life and TS/TS2 anyway) are devoid of these as far as I can remember. But the fake bloopers that they run with the credits are about 50% fart jokes. I wonder why.
Oh I guess that's why they are bloopers...(someone was telling me about an argument they had with someone trying to explain why they weren't really outtakes and had to be specifically made).
The plot of Shrek was totally straightforward. He gets sent on a quest to a castle, he fights a dragon, he comes back and gets the princess. The only twist was that at the end she turned into an ogre instead of him turning into a handsome man.
Now compare that with Bug's Life. How is Flik going to save the day? What happens when the identity of the circus bugs is exposed? Or when the bird catches fire? Of course these movies all share the basic ending of good triumphing over evil but Bug's Life takes a lot more twisty route getting there.
Then you have the Toy Story movies which actually have a quite interesting idea behind them, and are also cleverly done. What truly baffles me is how something so simple-minded as Shrek is supposed to appeal to adults. I can see why kids like it but can such a simple plot really capture an adult's imagination, unless they are simply watching the animation?
The other thing about Toy Story/Bug's Life is that they could not have been made as live action movies, unlike Shrek (whose basic plot has been made countless times). I haven't seen Monsters Inc. but I think it may show Pixar descending into mere competence as opposed to brilliance.
I fully agree with the point that you have to have a good plot, not just CG for its own sake. But while I loved Toy Story and Bug's Life, I thought that Shrek was in fact the poster child of CG for its own sake, with no redeeming plot. If you got rid of the fancy graphics, it's just a totally basic fantasy movie with a plot that is obvious in the first five minutes.
Gee do ya think Shrek is going to save the Princess and fall in love with her? Gosh what a surprise. It had some cutesy side jokes, and Cameron Diaz's avatar was certainly a render-o-babe, but that was about it. Diaz's reading was terrible, and Mike Myers talking in a Scottish accent is funny only if you know that he is actually Canadian (although that accent was actually his own idea I gather and a late change in the movie). I can picture some film execs watching this and cracking up each time Myers says "Donkey!" and Eddie Murphy does his thing. But they are only meta-funny, not actually funny. Just the fact that you think of the characters by their human voicers as opposed to their CG selves shows one of the problems.
Read the osopinion column I linked to above which discusses the 60K number (although oso seems to be dead right now). Basically there are some tools to find suspicious code (but not fix it), but they are still subject to human error/arrogance. Things like BoundsChecker have been used at Microsoft but I don't think it works on kernel-mode code which is where the best buffer overflow exploits can be found.
"If you have those three things, you can just put an if() in the code." True. Of course, you have to avoid an off-by-one boundary problem, you have to test against the length of the right array (I've done that one myself), you have to get the right index or pointer or whatever...in short, there are LOTS of ways of screwing up even with the right facts.
Most of that you have to get right just to pass it to a function. And how is the function written...does it expect to be told the length of the buffer including or not including a final '\0'? Is the second argument the allowed length and the third one the length to test, or vice versa? The key is taking the time to have the code check and having a mindset that this is something you need to guard against...how you do it is much less important.
Now it is true that Microsoft is very bad at sharing code between groups. How many times has strlen() been reimplemented because someone didn't like the one in the standard library? And the same is true of methodology.
You should understand that this UPNP code doesn't sound like it was done by the core NT team (here comes my bias as a former NT kernel developer). I can picture Steve Ballmer screaming five years ago about how hard it is to just stick a printer on the network and have it be discovered...so out of that comes the "Universal Plug and Play" team. Probably they are somewhere under Windows Me since that group is more consumer-focussed than NT/2000/XP. But of course they need a little piece of code that runs on XP. So some random person writes that code, maybe they are in the NT team, maybe not, maybe their code is run through PREFIX, maybe not. But when the code runs, it's got system-level access and can be used as an exploit. Meanwhile who is testing that code...probably a UPNP test team that is mostly focussed on some big matrix of machines and OSes and hardware devices, making sure that each device is detected by each machine and OS. Where in there is anyone going to test for buffer overflows in the XP code...nowhere is the answer. And if the XP team says, "in order to include code with XP you need to do all this stuff to verify it," the answer is probably "go away, we need to get UPNP working ASAP" (ironically, since UPNP is now going to be disabled on so many XP machines that when the hardware comes out next year, the whole scheme won't work anyway). I'm making some guesses here, but I bet the truth is pretty close to this. So there you have it hackers, find some piece of code that runs at high privilege on XP, but also involves some code that has to run on 2000 and Me and etc. and has enough external issues to distract a test team...that is where you will find your buffer overflow exploits.
In your work, how are you measured? I'm measured by how much code goes out the door marked "sold" without technical support calls.
When I worked at Microsoft I was not measured this way, which is unfortunate because it should be a component of the evaluation. We were evaluated on some combination of how much code we wrote, how respected we were in the team, and how many hours we worked. OK it was more than that, but the key is reviews were done every 6 months and once they were done they were never revisited. So questions like "how has this code held up after a year in the marketplace" never figure in someone's review. Maybe if Microsoft gets sued over an exploit and forced to lay out its engineering procedures in court, then it will get serious about penalizing developers for leaving around exploitable code.
Plus you couldn't actually fire someone for leaving in a buffer overflow. Although technically Microsoft employs people "at will" and can fire them at any time for any reason or no reason, in fact to avoid lawsuits they have an elaborate procedure of putting people on probation, which usually just results in them leaving for another group within Microsoft. If they actually fired someone for a buffer overflow the person would sue and bring in all these experts to talk about how hard it is to catch every one etc.
Of course they can be avoided with proper coding. You hardly need a separate function...to check for a basic buffer overflow you need to know the array in question, how much data can fit in there, and how much data is attempted being stuffed in there. If you have those 3 things, you can just put an if() in the code.
So it's not a question of not being able to do it, it's a question of not doing it. That's what I meant about hundreds of developers...one bad egg can spoil everything.
Consider this
article about the problem. Jim Allchin is quoted as saying, "We have gone through all code and, in an automated way, found places where there could be buffer overflow, and those have been removed in Windows XP." The automated way is things like PREFIX that I discuss in the osopinion article I linked to above (the big cleanup was done right after Windows 2000 shipped, thus the results appeared in Windows XP). But as I pointed out, you are still dependent on a developer having the will to really investigate the PREFIX report, honestly admit that a problem could be there, and go to the trouble of fixing it, rather than just try to hand-wave explain why it won't occur.
It's really hard to blame this on the test/QA team (even if they work in an environment with more enlightened development/test relationships than Microsoft). How many bad packets do you have to blast at something before hitting a vulnerability, if there is one? This kind of problem is *so much* easier to catch when the code is being written, or even via code review, than it is by experiment in a test lab. This is the kind of thing a developer really should be able to find when they are testing just their code. The lab can handle all the wierd interactions between different pieces of code.
Unfortunately when you have millions of lines of code, like Windows XP does, it is mind-numbing to go through all of them looking for this kind of thing. So now the barn door is open and the buffer overflows have escaped into the code, and they will have to be rounded up one at a time by being found "in the wild" as you put it.
There was two bugs reported here. One in SSDP that makes it possible to use XP to launch denial of service attacks, one that is reported as a buffer overflow.
So what is up with those buffer overflows...do Microsoft developers hate users and not care about quality? Well, no. It only takes one buffer overflow in the whole system that hundreds of developers have worked on, to make it vulnerable.
At Microsoft the ultimate way people are valued is at review time when bonuses, stock options, and raises are awarded. Do developers get hosed for leaving buffer overflows in? Well, not as of when I left (April 2000). But maybe that will change, slowly.
Eventually you have to stop accepting excuses like "Gee code is really complicated and I thought I was being careful" or "we really tried to think through this design" and recognize that essentially every buffer overflow comes from being lazy as a developer, or not accounting for what kind of garbage packets can come in off the net. If Microsoft starts emphasizing that you can be fired for leaving a buffer overflow in, then things might change. Of course it's a little unfair, there is no doubt lots of clunky code in there that just doesn't happen to expose an externally exploitable buffer overflow (and merely crashes the system or something), but you start emphasizing the necessity to go over things with a fine-tooth comb to prevent buffer overflows, it will improve all the code.
Because although there may be a few cases where someone really tried to check boundary conditions and just did it wrong in the code, in most cases developers are just being lazy about writing the code robustly to begin with. Plus if you have some code to prevent this and you write it wrong, you haven't tested your code properly anyway.
Thanks for the answers. I, former Microsoft programmer (but unbiased and honest, of course) am also angling to get on this committee. However where you are going for the DOJ nominated position, I am trying for the Microsoft one. I have been spamming contacts within Microsoft, with no luck so far unfortunately.
1) Do you think the proposed settlement is fair? I have my reservations, some of which I mentioned in my original responses. As you might guess, I'll be taking my own advice and submitting a public comment regarding my misgivings with the PFJ.
Did you read all that stuff in the competitive impact statement emphasizing (for the judge's benefit) how the settlement doesn't have to be the best one, just "reasonable" in some way...I wonder how true that is.
2) Do you think you would have the technical chops to be hired by Microsoft as a programmer, if you for some reason chose to apply? The "chop" I don't have is youth. I get the impression that Microsoft likes to get their technical people fresh out of school. I'm not sure that an over-40 guy would do well as fresh-caught talent.:)
These days with the size of the company they take what they can get...maybe in your case it would be more a question of "do you think you could manage programmers at Microsoft". Anyway the key is that you can sit across the table from some Microsofties and believe you are as smart as them.
3) The competitive impact statement implies that the job is a full-time one based in Redmond, WA. Do you plan to move there if selected?
I have no problems moving, although it might be better -- as this is a finite-term position -- to take an apartment in the Redmond area and keep my home in Nevada. Then again, there is all this here networking technology that Microsoft and others are advertising...
Microsoft even has an office in Reno, that does all their licensing. But you should come up to Redmond, the weather's great.
Working hours? You've got to be kidding. Unless there is a miracle, I expect that after the first two months I'll be putting in at least 80 hours a week. About what I'm used to as a technie, so no problem.
Dude! It says you can hire staff...when (I mean if) we get on the committee we'll have to have a talk about that.
The scoop I have been hearing from inside Microsoft is that they really do want to comply with the agreement. So maybe those committee folks really will be playing Ages of Empire all day.
On the off chance that you are still compulsively monitoring this thread to see if any other comments trickle in (I know I did), I have a few more questions:
1) Do you think the proposed settlement is fair?
2) Do you think you would have the technical chops to be hired by Microsoft as a programmer, if you for some reason chose to apply?
3) The competitive impact statement implies that the job is a full-time one based in Redmond, WA. Do you plan to move there if selected?
4) The committee can set a reasonable salary for itself (paid by Microsoft!). What would you think of charging and how many hours a week would you expect to work?
From some of the questions asked here, it appears that some people expect you to be sitting next to Bill and Steve, approving or denying every product feature they request. In fact, if you read the language in the
Proposed Settlement and the
Competitive Impact Statement, it appears that the job is more to ensure that Microsoft is complying with the technical aspects of the agreement, which Microsoft claims it is going to do anyway. Also, the committee is allowed to hire staff, travel, etc. as needed.
So do you picture the committee as overseeing a large group of people who are busy reading code, checking API documentation, analyzing network traffic, etc, or do you see it more as just the three committee members sitting around playing Ages of Empires, waiting for someone to call and complain about something?
- adam
people make fun of Bob, but...
on
Do You Remember Bob?
·
· Score: 2, Interesting
Think about what Bob was...a layer on top of the OS, that simplified it for novice users, categorized things, made it more "friendly", etc.
The first version was widely reviled, but the team starting working on a second one. Now it is often true that the third version of a product is the one that catches on -- the first one is rushed out, the second has all the stuff that was supposed to go in the first, then the third can actually respond to user feedback and become useful. But for some reason, Microsoft untypically cancelled Bob 2.0 in mid-development.
Now if you imagine Bob continuing to evolve and eventually adding Internet access (still categorized, simplified, friendlier, etc), then it could have become...AOL. People make fun of AOL also (for similar reasons), but it's a pretty successful company and viewed in many ways as the only tech competitor to Microsoft. Now imagine if Microsoft had short-circuited that with Bob 5.0.
This cross platform stuff is the crack dream of GUI programming going back 20 years. You get least-common denominator support for the underlying GUI, and another layer of code to harbor bugs.
It's a great example of how an idea that seems good when discussing it in a CS class, falls apart where the rubber meets the road.
Slashdot Mirror
"Security works best when it's designed into the system from the beginning, so a lot of what they've already done is going to have to be rewritten."
This is false. XP, based on NT, has security built in. The vulnerabilities discovered so far basically seem to be in two camps:
1) Buffer overflows left in the code -- rewriting won't help these, it will likely just introduce more. They just need to be found and fixed. Microsoft is in fact going over all its code line-by-line, but I can't imagine that glassy-eyed developers spending a month doing that is actually going to find all the overflows.
2) Bad design, in particular allowing foreign code to execute. I.e. the various Outlook email viruses. These need to be removed, which is a basic change in how Microsoft thinks (security over nifty features) but again you don't need to rewrite Outlook to stop if from executing scripts by default.
Methinks Schneier might be fantasizing a bit about Microsoft *having* to do this, of saying, as he puts it, "We're going to put the entire .NET initiative on hold, probably for years, while we work the security problems out." It seems like he would like to see Microsoft fall behind in the market because they have to throw all their current code away. Plus he hates SOAP (since it sneaks past firewalls inside HTTP), which is one of the technologies .NET is based on.
Personally I think this is basically more marketing hype from Microsoft. Because they are still not going to penalize developers who write insecure code (something that was bandied about but not adopted) -- it will still be, "Oops, we did it again". So with no real connection between good code and stock options, developers at Microsoft won't change.
- adam
".NET is also the collective name given to various bits of software built upon the .NET platform. These will be both products (Visual Studio.NET and Windows.NET Server, for instance) and services (like Passport, HailStorm, and so on)."
is misleading. Visual Studio and Server are not built on .NET, one is a dev environment and one is an operating system. Hailstorm is a ".NET application" and that type of application is the reason for .NET.
I could be wrong of course. Maybe .NET will turn out to be just a new runtime model...which seems a big waste of an opportunity. The only real advance I can see is that it gives Microsoft a chance to redo all their libraries so they do security checks...which is very topical, but doesn't seem worthy of all the hype about .NET
- adam
- adam
And Microsoft has provided the answer: Here is the runtime model, here are the APIs you call, here are some tools you can use, here is how to get help if you have problems.
Now substitute a web of connected personal computers -- the Internet -- for a single one, and developers are still asking, "How do I write an application?" And Microsoft's answer is, .NET.
DOS provided very few services to application writers, but with the Windows APIs, things got more sophisticated: support for graphics, for printing, for various other input and output devices, and eventually for networking. These were filtered through a standard Microsoft-provided operating system to various third-party devices, each with their own device driver, which performed the actual work.
In the .NET world, the "API" will handle Internet-related issues such as password verification, price calculation, payment, and so on. The "operating system" will be a set of always-available Web sites that may then dispatch the actual work to third-party sites -- the "device drivers" in the .NET model.
That is an excerpt from a longer article which I wrote back in November 2000.
- adam
- adam
You're simply naive. Last time I checked advertising was legal, even for Microsoft.
- adam
1) He is not self-publishing, since technically what he writes has to be approved by the slashdot crew. Now I don't know if they actually reject anything he writes (any more than Newsweek ever rejects something by one of their regular columnists once they have established cred), but still it is different than a blog.
2) It is not on a site devoted exclusively to him. As a result, there is a lot of discussion about what he writes because the site has people who are both for and against what he writes (due to all the other content). On a blog, people who disagree with the person's viewpoints tend not to read the blog at all, so the discussion is very one-sided if it exists at all.
3) On the downside, Katz (as far as I know) does not participate in the debate about his writings, but merely floats above it all. This is also un-blog-like, although arguably not an improvement.
- adam
Furthermore, bloggers get "pundit syndrome" where because their views are "published", they feel they know more than others, thus reinforcing their tendency to intone imperiously rather than enter into debates. This further destroys any chance for a community to form, unless you count a swarm of boot-licking toadies congregating around one blog to be a community.
- adam
Anyway the core code is written in C and will stay that way. XP undoubtedly is the most secure OS they have released, but you have things like the UPNP exploit slip through. Not part of the main code, probably written by some college new hire, and no doubt checked in *after* the big security sweep was done (which was just when Windows 2000 shipped). Still that is the only exploit I have heard of in XP so far (excluding Outlook and IIS ones) and may in fact wind up being the only one, because most of the code *was* scrubbed pretty hard.
But to really drive it home you have to tie it to salary/bonus/option grants because that is the real way people are measured at Microsoft.
- adam
Yeah right. What crucible. A buffer overflow is not something a"security review" is going to find. You just have to write the code carefully.
Compensation plans of Microsoft product engineers, such as raises and bonuses, will also be tied to how secure their products are.
This gives hope however. Reviews at Microsoft are always just about the last six months, so nobody was ever dinged for a bug that turned up a year after they shipped. But now maybe that will happen.
More here.
- adam
Are they serious? Can Clippy spread a virus? I never heard of that.
Ahhhh he's coming out of the computer....
- adam
Recovery of the "this" pointer means that any function will magically have a pointer to the object it is working on available. Now normally this doesn't matter much because you can just have the function take itself as an argument (or a magically cast-to-void "handle" if you want to be opaque about it). But when you start to have inheritance, it can be tricky for the calling function to figure out what pointer to use. The OO language will do this for you.
Late binding means you can link at runtime, not compile time. C++ offers this recovery but not late binding. Java and COM offer both.
The rest is mostly OO hype. The big argument about how you can encapsulate everything inside a function is bogus because then you just convert it into a documentation issue, of knowing what exact random thing the designer of the function has decided it is appropriate to do. This is no different in OO or non-OO.
The best, really the only successful realization of the OO dream of small interconnectable pieces so far is the Unix command line tools with pipes between them. Sure the data exchange format is trivial and limited, but the system actually works, and users can easily join together small reusable pieces of code to accomplish (most of) what they desire. The fact that this system is 30 years old and has not been improved upon just shows that <insert cliche here>.
- adam
Oh I guess that's why they are bloopers...(someone was telling me about an argument they had with someone trying to explain why they weren't really outtakes and had to be specifically made).
- adam
Now compare that with Bug's Life. How is Flik going to save the day? What happens when the identity of the circus bugs is exposed? Or when the bird catches fire? Of course these movies all share the basic ending of good triumphing over evil but Bug's Life takes a lot more twisty route getting there.
Then you have the Toy Story movies which actually have a quite interesting idea behind them, and are also cleverly done. What truly baffles me is how something so simple-minded as Shrek is supposed to appeal to adults. I can see why kids like it but can such a simple plot really capture an adult's imagination, unless they are simply watching the animation?
The other thing about Toy Story/Bug's Life is that they could not have been made as live action movies, unlike Shrek (whose basic plot has been made countless times). I haven't seen Monsters Inc. but I think it may show Pixar descending into mere competence as opposed to brilliance.
- adam
Gee do ya think Shrek is going to save the Princess and fall in love with her? Gosh what a surprise. It had some cutesy side jokes, and Cameron Diaz's avatar was certainly a render-o-babe, but that was about it. Diaz's reading was terrible, and Mike Myers talking in a Scottish accent is funny only if you know that he is actually Canadian (although that accent was actually his own idea I gather and a late change in the movie). I can picture some film execs watching this and cracking up each time Myers says "Donkey!" and Eddie Murphy does his thing. But they are only meta-funny, not actually funny. Just the fact that you think of the characters by their human voicers as opposed to their CG selves shows one of the problems.
- adam
- adam
- adam
Most of that you have to get right just to pass it to a function. And how is the function written...does it expect to be told the length of the buffer including or not including a final '\0'? Is the second argument the allowed length and the third one the length to test, or vice versa? The key is taking the time to have the code check and having a mindset that this is something you need to guard against...how you do it is much less important.
Now it is true that Microsoft is very bad at sharing code between groups. How many times has strlen() been reimplemented because someone didn't like the one in the standard library? And the same is true of methodology.
You should understand that this UPNP code doesn't sound like it was done by the core NT team (here comes my bias as a former NT kernel developer). I can picture Steve Ballmer screaming five years ago about how hard it is to just stick a printer on the network and have it be discovered...so out of that comes the "Universal Plug and Play" team. Probably they are somewhere under Windows Me since that group is more consumer-focussed than NT/2000/XP. But of course they need a little piece of code that runs on XP. So some random person writes that code, maybe they are in the NT team, maybe not, maybe their code is run through PREFIX, maybe not. But when the code runs, it's got system-level access and can be used as an exploit. Meanwhile who is testing that code...probably a UPNP test team that is mostly focussed on some big matrix of machines and OSes and hardware devices, making sure that each device is detected by each machine and OS. Where in there is anyone going to test for buffer overflows in the XP code...nowhere is the answer. And if the XP team says, "in order to include code with XP you need to do all this stuff to verify it," the answer is probably "go away, we need to get UPNP working ASAP" (ironically, since UPNP is now going to be disabled on so many XP machines that when the hardware comes out next year, the whole scheme won't work anyway). I'm making some guesses here, but I bet the truth is pretty close to this. So there you have it hackers, find some piece of code that runs at high privilege on XP, but also involves some code that has to run on 2000 and Me and etc. and has enough external issues to distract a test team...that is where you will find your buffer overflow exploits.
In your work, how are you measured? I'm measured by how much code goes out the door marked "sold" without technical support calls.
When I worked at Microsoft I was not measured this way, which is unfortunate because it should be a component of the evaluation. We were evaluated on some combination of how much code we wrote, how respected we were in the team, and how many hours we worked. OK it was more than that, but the key is reviews were done every 6 months and once they were done they were never revisited. So questions like "how has this code held up after a year in the marketplace" never figure in someone's review. Maybe if Microsoft gets sued over an exploit and forced to lay out its engineering procedures in court, then it will get serious about penalizing developers for leaving around exploitable code.
Plus you couldn't actually fire someone for leaving in a buffer overflow. Although technically Microsoft employs people "at will" and can fire them at any time for any reason or no reason, in fact to avoid lawsuits they have an elaborate procedure of putting people on probation, which usually just results in them leaving for another group within Microsoft. If they actually fired someone for a buffer overflow the person would sue and bring in all these experts to talk about how hard it is to catch every one etc.
- adam
So it's not a question of not being able to do it, it's a question of not doing it. That's what I meant about hundreds of developers...one bad egg can spoil everything.
Consider this article about the problem. Jim Allchin is quoted as saying, "We have gone through all code and, in an automated way, found places where there could be buffer overflow, and those have been removed in Windows XP." The automated way is things like PREFIX that I discuss in the osopinion article I linked to above (the big cleanup was done right after Windows 2000 shipped, thus the results appeared in Windows XP). But as I pointed out, you are still dependent on a developer having the will to really investigate the PREFIX report, honestly admit that a problem could be there, and go to the trouble of fixing it, rather than just try to hand-wave explain why it won't occur.
It's really hard to blame this on the test/QA team (even if they work in an environment with more enlightened development/test relationships than Microsoft). How many bad packets do you have to blast at something before hitting a vulnerability, if there is one? This kind of problem is *so much* easier to catch when the code is being written, or even via code review, than it is by experiment in a test lab. This is the kind of thing a developer really should be able to find when they are testing just their code. The lab can handle all the wierd interactions between different pieces of code.
Unfortunately when you have millions of lines of code, like Windows XP does, it is mind-numbing to go through all of them looking for this kind of thing. So now the barn door is open and the buffer overflows have escaped into the code, and they will have to be rounded up one at a time by being found "in the wild" as you put it.
- adam
So what is up with those buffer overflows...do Microsoft developers hate users and not care about quality? Well, no. It only takes one buffer overflow in the whole system that hundreds of developers have worked on, to make it vulnerable.
At Microsoft the ultimate way people are valued is at review time when bonuses, stock options, and raises are awarded. Do developers get hosed for leaving buffer overflows in? Well, not as of when I left (April 2000). But maybe that will change, slowly.
Eventually you have to stop accepting excuses like "Gee code is really complicated and I thought I was being careful" or "we really tried to think through this design" and recognize that essentially every buffer overflow comes from being lazy as a developer, or not accounting for what kind of garbage packets can come in off the net. If Microsoft starts emphasizing that you can be fired for leaving a buffer overflow in, then things might change. Of course it's a little unfair, there is no doubt lots of clunky code in there that just doesn't happen to expose an externally exploitable buffer overflow (and merely crashes the system or something), but you start emphasizing the necessity to go over things with a fine-tooth comb to prevent buffer overflows, it will improve all the code.
Because although there may be a few cases where someone really tried to check boundary conditions and just did it wrong in the code, in most cases developers are just being lazy about writing the code robustly to begin with. Plus if you have some code to prevent this and you write it wrong, you haven't tested your code properly anyway.
More ruminations at this osopinion article.
- adam
1) Do you think the proposed settlement is fair? I have my reservations, some of which I mentioned in my original responses. As you might guess, I'll be taking my own advice and submitting a public comment regarding my misgivings with the PFJ.
Did you read all that stuff in the competitive impact statement emphasizing (for the judge's benefit) how the settlement doesn't have to be the best one, just "reasonable" in some way...I wonder how true that is.
2) Do you think you would have the technical chops to be hired by Microsoft as a programmer, if you for some reason chose to apply? The "chop" I don't have is youth. I get the impression that Microsoft likes to get their technical people fresh out of school. I'm not sure that an over-40 guy would do well as fresh-caught talent. :)
These days with the size of the company they take what they can get...maybe in your case it would be more a question of "do you think you could manage programmers at Microsoft". Anyway the key is that you can sit across the table from some Microsofties and believe you are as smart as them.
3) The competitive impact statement implies that the job is a full-time one based in Redmond, WA. Do you plan to move there if selected? I have no problems moving, although it might be better -- as this is a finite-term position -- to take an apartment in the Redmond area and keep my home in Nevada. Then again, there is all this here networking technology that Microsoft and others are advertising...
Microsoft even has an office in Reno, that does all their licensing. But you should come up to Redmond, the weather's great.
Working hours? You've got to be kidding. Unless there is a miracle, I expect that after the first two months I'll be putting in at least 80 hours a week. About what I'm used to as a technie, so no problem.
Dude! It says you can hire staff...when (I mean if) we get on the committee we'll have to have a talk about that.
The scoop I have been hearing from inside Microsoft is that they really do want to comply with the agreement. So maybe those committee folks really will be playing Ages of Empire all day.
- adam
1) Do you think the proposed settlement is fair?
2) Do you think you would have the technical chops to be hired by Microsoft as a programmer, if you for some reason chose to apply?
3) The competitive impact statement implies that the job is a full-time one based in Redmond, WA. Do you plan to move there if selected?
4) The committee can set a reasonable salary for itself (paid by Microsoft!). What would you think of charging and how many hours a week would you expect to work?
Thanks.
- adam
So do you picture the committee as overseeing a large group of people who are busy reading code, checking API documentation, analyzing network traffic, etc, or do you see it more as just the three committee members sitting around playing Ages of Empires, waiting for someone to call and complain about something?
- adam
The first version was widely reviled, but the team starting working on a second one. Now it is often true that the third version of a product is the one that catches on -- the first one is rushed out, the second has all the stuff that was supposed to go in the first, then the third can actually respond to user feedback and become useful. But for some reason, Microsoft untypically cancelled Bob 2.0 in mid-development.
Now if you imagine Bob continuing to evolve and eventually adding Internet access (still categorized, simplified, friendlier, etc), then it could have become...AOL. People make fun of AOL also (for similar reasons), but it's a pretty successful company and viewed in many ways as the only tech competitor to Microsoft. Now imagine if Microsoft had short-circuited that with Bob 5.0.
- adam
It's a great example of how an idea that seems good when discussing it in a CS class, falls apart where the rubber meets the road.
- adam