Why don’t I agree with Bruce Schneier all the time :)


Friday’s post about security blogs apparently contained a bit of unintended controversy.

When describing Bruce Schneier’s blog, I said “I don’t agree with a lot of what he says”.  Apparently this is heresy in some parts, although I don’t understand why.  Bruce is unquestionably a very, very smart man (and an excellent writer, I simply loved Applied Cryptography), but he’s no Chuck Norris 🙂

On most topics – security architecture, crypto design, threat analysis, etc, Bruce is remarkable.  I find most of what he writes to be insightful.

But Bruce seems to have a complete blind eye when it comes to Microsoft.  To my knowledge, even though essentially every other serious security analyst has acknowledged that Microsoft has done a staggering amount of work to improve the security of its products, Bruce still maintains that Microsoft has no clue when it comes to security.  That stings.

The #2 hit in a search for Bruce Schneier Microsoft is: http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1011474,00.html which includes: ” Microsoft is certainly taking it more seriously than three years ago, when they ignored it completely. But they’re still not taking security seriously enough for me. They’ve made some superficial changes in the way they approach security, but they still treat it more like a PR problem than a technical problem”.  This couldn’t be farther from the truth (the #1 hit is Schneier’s FAQ about the PPTP analysis he did where he neglected to acknowledge the work that Microsoft did to rectify the issues he found after his analysis).

And then there was this gem (from February of this year): http://www.schneier.com/blog/archives/2007/02/drm_in_windows.html.  He took Peter Gutmann’s article and accepted it as the gospel truth, even though Gutmann had absolutely no factual basis for his speculation – Gutmann hadn’t verified a single one of his claims, heck he hadn’t even installed Vista at the time he wrote his paper.

On the basis of one paper from someone who had never even RUN Vista, Schneier leapt to the conclusion that Microsoft had embedded DRM into all levels of the operating system and that was a reason to avoid Vista.

 

For the following 5 paragraphs, please note: I AM NOT A LAWYER.  I AM NOT GIVING A LEGAL OPINION, THESE ARE JUST MY THOUGHTS.

I also believe that he hasn’t fully thought out his position on holding companies financially liable for the security holes in his product.  At first blush his idea is attractive, but I firmly believe that the consequences of his idea would totally destroy the Internet as we know it today.

It’s also entirely possible that it would kill the open source movement (talk about unintended consequences).  Let’s say that there’s a security vulnerability found.  If the vulnerability is found in a closed source product (or in proprietary code), then the corporation would be the only one that could be held liable for the damages – the individual developer would be protected by the corporate liability shield. 

But for open source projects, often there is no such corporate liability shield (I could imagine scenarios where a corporate liability shield might apply, but I don’t think they apply in general).  So who pays up if a vulnerability is found in an open source project?  The only likely target is the individual developer (or developers) who introduced the defect (I suspect that those involved in the distribution that contained the vulnerable code would also be targeted).

This means that it’s highly likely that the individual contributors to open source projects would be held personally financially liable for security vulnerabilities they introduce.  So to contribute to open source projects, you’d have to have many millions of dollars of personal liability insurance (or run the risk of financial ruin if a mistake is found in your code).  That is highly likely to result in a stifling of the open source movement, and there’s no easy way to work around it.

It’s also likely to decrease the likelihood that a corporation would adopt an OSS solution.  Consider the situation where a bank (or major retailer) is worried about having its customer records hacked.  Since the bank/retailer is going to be held responsible for its security breaches, then the bank/retailer has to factor that risk when it chooses a vendor for its database solution.  If the bank/retailer thinks it can sue the software developer who developed the database solution in the event of a breach, and it has two choices for a database vendor, one of them developed by a bunch of people who don’t have any real assets and the other comes from a company with insurance and assets, it would be crazy to choose the one where you have no one to sue.

 

Those are a couple of reasons why I disagree with Bruce Schneier on occasion.

Comments (44)

  1. Anonymous says:

    Thanks Larry – I was getting pretty fed up with Bruce’s baseless remarks about Windows and Microsoft. Sure he knows his crypto and I like his book as much as the next guy but he is just plain ignorant when it comes to Microsoft security and technology.

  2. Anonymous says:

    Pretty good reasons for me. I work in a division where the mere mention of Microsoft can get people on their soap box.

  3. Anonymous says:

    "This means that it’s highly likely that the individual contributors to open source projects would be held personally financially liable for security vulnerabilities they introduce."

    I would dispute this point. The source code is there for all to see. Any group that wishes to use the code can either do their own security review or trust the contributors, based on their group’s level of trust and paranoia. It’s their choice, nothing is being hidden from them. In the case of closed source, I have no choice but to trust the company’s assertions about its security and the steps they’ve taken to review it for vulnerabilities.

    However, I think I see where you are coming from with the argument. A doctor who happens upon an accident and offers medical help has to be protected by Good Samaritan laws nowadays. It’s just common sense, but it still needs to be legislated.

  4. Dave,

     I decided not to even go into the volunteer help issue – apparently the law gets really complicated there.

     The availability of source code doesn’t change the liability issue (there have been numerous studies that have shown that open source code has roughly the same number of defects as closed source code).  This is a product liability issue, not a code quality or trust issue.

    The question is: to whom does liability attach?  In the case of closed source code, liability clearly attaches to the corporation and only to the corporation (in fact, that’s the entire purpose of the corporate liability shield).  In the case of FOSS code, it’s not clear where liability attaches, my belief is that it attaches to the developer who introduced the defect in the first place (because there’s no corporation to sue).

  5. Zian Choy says:

    I’ll second Kenny’s remarks.

    I have similar mixed feelings about Schneier’s blog. But I still syndicate his feed.

    So I take 1 part Schneier, 1 part Microsoft blogs, and mix. 🙂

  6. Anonymous says:

    "my belief is that it attaches to the developer who introduced the defect in the first place (because there’s no corporation to sue)."

    I believe that may be true in law, but will never be carried out in reality. As Steve Dallas once said in a Bloom County comic strip, "Never sue poor people". Any lawsuit would most likely find it’s way back to a corporation. For Windows OS software, somehow Microsoft would be pulled in. For Linux, probably IBM, maybe Red Hat or some other distributor.

  7. Scott, if that’s the case, then see my penultimate paragraph.  No corporation in their right minds would ever adopt a FOSS solution if they didn’t have anyone to sue in the case of a breach, they would stick only with closed source systems.  They might go with a major commercial distribution, but that has its own set of issues – in that case, the corporation that owns the distribution would bear the lions share of the liability for any vulnerabilities.  That in turn means that the corporation would be MUCH more careful about what packages are included in a distribution – most of the current packages that are included in most *nix distributions would be dropped on the floor as being too much risk to include.

  8. Dean Harding says:

    You gotta give him credit for being one sane voice in a sea of madness after 9/11. He also certainly makes his opinions of Microsoft quite clear (and it does seem to be a rather dated opinion these days) but he’s not *too* bad. You can’t take anything anyone says as gospel, though.

    I don’t get his obsession with squids, either:-)

  9. Anonymous says:

    I haven’t researched this, but I always thought the issue wasn’t that software developers have liability *now* for security issues in their software, but that some future law ought to be crafted such that they *should* be.

    In that case, since the law is hypothetical in the first place, to assume that liability *would* attach to individual developers is to argue against a straw man: the law could be crafted either way.

    It’s reasonable to argue that any law which made individual developers liable for defects in open source code would be ridiculous; I’d agree with that argument myself. But that isn’t the only way such a liability law could be crafted. Personally, I’m tentatively in favor of a law which says that if you sell someone software or sell them support for software, then you become liable at the point that money changes hands.

    It becomes a little more complicated if you want to cover things like individuals being sponsored to work on open source software, but it seems like it should be possible to craft a law to cover that situation too – some provision allowing software developed under contract to an organization to have the liability waived as part of the initial contract before development began, for example.

    I’m not saying there aren’t any valid arguments against making software developers liable for security flaws, I just don’t think *that* argument holds up.

  10. Dean: I 100% agree with you on the sane voice in a sea of madness.  As I said: I agree with Bruce most of the time.

    And I don’t get the friday squid blogging thingy, but I know that there are other bloggers that do it.  I figure it’s sorta like my boss’s "Hawaiian Shirt Friday".

    Stuart: Why should open source development get pass from liability laws when closed source doesn’t?  I’m having a hard time understanding such a broad exception to product liability laws.

  11. Anonymous says:

    Schneier’s opinion: "[…] holding companies financially liable for the security holes in his [their?] product."

    You ask: "So who pays up if a vulnerability is found in an open source project?"

    You answer: "[…] highly likely that the individual contributors to open source projects would be held personally financially liable for security vulnerabilities they introduce."

    The open source projects you’re talking about are not run by companies.  Schneier’s opinion as you state it here therefore does not suggest such an answer.  It’s a straw man.

    "It’s also likely to decrease the likelihood that a corporation would adopt an OSS solution."

    Shouldn’t Microsofties like it then?

  12. Anonymous says:

    Hey, I never said open source development gets a pass.

    I said that it should apply when money changes hands.

    If you download open source software for free from Joe Random, caveat downloador, you bear the responsibility for the choice you made to do that.

    If you purchase Red Hat Enterprise Linux or whatever SUSE’s enterprise edition is called from Novell, or purchase Ubuntu with support from Canonical, or get an enterprise Linux solution installed and supported by IBM, then that’s no different than if you’re buying Windows from Microsoft, and liability attaches.

    Your position perhaps would be that Red Hat etc would never accept such a law, they couldn’t possibly accept the liability of code from random contributors for the same reason that Microsoft constantly argues it can’t possibly bundle Paint.Net with the OS instead of Paint. I’d argue that the mere fact that these vendors DO ship open source code and DO accept the risk of all the potential liability that Microsoft considers so unacceptable, tells you that in fact they don’t feel that way.

    (And yes, I’m implying that if Microsoft made Windows a free and unrestricted download, then they’d also get a pass on liability for it)

  13. A: I have no idea if Microsofties should like it or not.  Personally I think it’s a horrible idea on many levels (do you have any idea how much ANY software would cost if the price of the software included the potential liability for any security defects was included in the price?)

    If there’s no company, liability attaches to the individual.  It’s one of the big reasons that corporations exist.

  14. Stuart: If liability only attaches when money changes hand, then no corporation will ever adopt a FOSS project that’s not associated with another corporation.  Otherwise the liability for that corporation will be too high.

  15. Anonymous says:

    Larry, I addressed that point, I thought. Aren’t Red Hat, IBM et al convincing counterexamples?

    Microsoft considers the liability cost of possible IP infringement in Paint.Net completely impossible to even consider, even though there’s no hint that any IP is actually infringed.

    And yet Red Hat, Novell, IBM, Canonical, and a whole host of other companies ship and support entire operating systems written by developers just as "amateur" as the developers of Paint.Net and with even less "formal" assurance that the IP is clean.

    Why does that work for them and not for Microsoft? Who knows. Point is that your claim that "no company would do this" doesn’t square with the fact that companies *do* today do something that Microsoft considers just as unacceptable for the exact same reasons.

    The way I see it, open source vendors act as "liability shields" for their customers. And that applies perfectly well today for IP infringement liability, same as in a hypothetical future for security liability.

  16. Anonymous says:

    I’m not sure it would be the death of open source in a global sense. Even if it [liabilities for vulenerabilities in OSS] did kill it (which is a very extereme take, "stifle in some circumstances" would seem more likely to me) in the US the rest of the world would probably shrug shoulders, possibly shake heads knowingly, maybe even snigger a little and then get on with using and writing OSS.

    Perhaps litigation laws should be changed?

  17. Dean Harding says:

    > I’d argue that the mere fact that these vendors DO ship open source code and DO accept the risk

    > of all the potential liability that Microsoft considers so unacceptable, tells you that in fact

    > they don’t feel that way.

    They feel the risk is acceptable *today* with the laws as they currently stand. But if they were 100% liable for all bugs in the code, I don’t think there’d be much of a business case for them to accept outside contributions from anybody (unless the liability could then be passed down to them).

    The point is, Bruce wants the person who created the bug to be liable (which is fair enough if the person is a corperation) but in the case of OSS, the person who creates the bug cannot reasonably be liable for it.

  18. Anonymous says:

    Larry, thanks for this response. I was one of those who questioned you about this. Whether or not I agree with your response, a clarification was in order simply because Bruce generally speaks common sense like Seattlites drink espresso.

  19. Stuart: See Dean’s response.  Right now, there is no liability for software security defects, so there’s no issue with accepting contributions from non-employees.  If there was liability for software security defects, it’s not clear that companies like RedHat etc would be willing to accept liability from people who are volunteers.

    See my comment at the beginning about liability w.r.t. volunteer labor – if your car is totaled by a volunteer working for Meals-On-Wheels (or Habitat for Humanity or <pick your favorite charity that has driving as a part of its responsibilities>) does it mean that somehow Meals-on-Wheels AND the driver aren’t responsible?  Currently I don’t believe it does even though the driver was a volunteer working for the organization.

    The rules get REALLY murky when dealing with volunteer labor.

  20. Anonymous says:

    > On the basis of one paper from someone who had never even

    > RUN Vista, Schneier leapt to the conclusion that Microsoft

    > had embedded DRM into all levels of the operating system

    Interesting.  I had read a whitepaper on Microsoft’s site itself about protected processes in Vista, and that gave me the same impression that Mr. Gutman’s paper gave to Mr. Schneier.  At the time, I had not even seen or heard of Mr. Gutman’s paper.

    > and that was a reason to avoid Vista.

    I didn’t draw that conclusion from Microsoft’s paper, but I didn’t draw the opposite conclusion either.

    > Consider the situation where a bank (or major retailer) is

    > worried about having its customer records hacked.  Since the

    > bank/retailer is going to be held responsible for its security

    > breaches, then the bank/retailer has to factor that risk when

    > it chooses a vendor for its database solution.

    Considering that this is already the situation in some countries, I think that Mr. Schneier’s opinion would neither increase nor decrease the adoption of OSS.  Banks already have to figure out how to protect themselves, at least in some countries.

    It made me really comfortable (not) when a bank in the US was sending out spams on behalf of a hacker.  (This does not mean a hacker sending out phishing spams that pretend to be a bank.)

    It made me really comfortable (not) when a nuclear laboratory in Turkey was sending out spams on behalf of hackers.  The second time was after I’d already reported the first time to their administrators.  It made me even more comfortable (not) when a nuclear laboratory in the US was sending out spams on behalf of hackers, and they were bouncing e-mail reports because they didn’t even register their domain properly.  Yeah, so maybe there were no other breaches in their systems, their bots were only accepting spamming instructions and sending out spams but ignoring instructions to send out copies of secret files.  Should I care whether they were running OSS or monopolyware?

    > Why should open source development get pass from liability

    > laws when closed source doesn’t?

    Although that was answered by the person you asked, I think there are more answers to consider.  One is that the maker is publishing their usage limitations for all to see, so that if you want to know what cannot safely be done with their software then theoretically you can read it and see.  One is that if you need an adjustment to the software to make it safe for you to use then theoretically you can make that adjustment.

  21. Anonymous says:

    Why doesn’t that apply to liability for IP infringement, though? It’s not like the theoretical possible damages for copyright or patent infringements are any less severe than for defect liability. How many billions was the SCO suit for?

  22. Stuart, I suspect it does.  And the theoretical damages for defects are WAY more than the damages for IP infringement.

    Consider the amount of damage a breach like TJX could cause – millions of customers credit card numbers siphoned off over the course of years – the liability to individual consumers is small, but that’s because the credit card companies are swallowing the debt.  If they had the ability to sue TJX to recover those damages, the would.

    Yes, the damages to Microsoft (or any other closed source organization) for a major IP breach would be large, but it’s not even vaguely in the same orders of magnitude as the potential liability of a single security defect.

  23. Anonymous says:

    I just can’t understand how one can speak about liabilities regarding anything that applies to software, let alone security issues. According to EULAs I encounter, all liability is in the court of the user. I mean… from EULA of my VS2003: "MICROSOFT AND ITS SUPPLIERS PROVIDE THE SOFTWARE AND SUPPORT SERVICES (IF ANY) AS IS AND WITH ALL FAULTS, AND HEREBY DISCLAIM ALL OTHER WARRANTIES yada-yada-yada". I read that as "no warranty wrt to how the software works, period".

    Therefore, I find the whole liability discussion hypothetical.

    There may be software that holds itself responsible for what it does, but it surely isn’t MSs or FOSSs as we know it?

  24. Anonymous says:

    Fair point.

    How about "liability capped at the price you paid for the software/support, plus legal fees"? Or at some multiple of the price you paid?

    It seems like it ought to be possible to create the incentives Schneier wants for companies to produce secure software without making the damages completely unbounded.

  25. Anonymous says:

    I think damages are legitimate in some cases, but there should be obvious limitations.  

    First, we all know that many software companies make exagerated claims about what features their products offer.  False claims like that should be immediately result in treble damages – refunds of thrice the cost of the software.  Should a company hard sell others on non-yet implemented features then it should be liable for full reimbursement of all costs a customer incurs in purchasing, accomodating, and replacing the software.  That hits the dishonest companies.

    Second, if a company develops and delivers a product where ANY feature doesn’t work due to a significant bug (one that affects over 10% of users for instance) the company must provide a patch for that bug or refund the purchase price.  That hits the companies that rush products to market too early.

    Third, every software company/provideer must make both binaries and source code freely available to all former customers when they orphan a product.  From the biggest version of windows down to the tiniest of applications, there should be no leaving a former customer stranded with no way to use or retrieve their data or reinstall their software.  If a business goes under then bankruptcy courts should seize and release this material.  If a business goes under with no court supervision then the software assets are automatically assumed orpaned and released to public domain.  If a software product line is shut down, the business in mandated to do the same and if it fails to within reasonable time the release is automatic.  No loopholes allowed where the company claims to support it for an exhorbitant price.  That hits the careless, the greedy, and the poorly run companies.

    yada yada yada

  26. Anonymous says:

    Larry, can you come up with some examples where a company or open source project was found liable for non-malicious code problems? (With that term I’m trying to exclude situations like back doors intentionally and obviously added by a company and/or person to disable the software or allow unauthorized access.)

  27. Dave, I can’t because according to the current law (as I understand it – IMNAL), in general liablity doesn’t attach for software defects.

    But Bruce Schneier (and others) are advocating attaching liability for software defects – holding software developers responsible for their bugs.

    J. Simpson: So you can’t say that your browser was "designed to be secure from the bottom up", that your database is "Unbreakable", etc?

    Stuart: I’m actually not interested in trying to figure out how to make this work.  I’m not a lawyer or legislator so nothing I come up with will really have any effect in the real world.

  28. Anonymous says:

    Tuesday, June 19, 2007 3:17 AM by Goran

    > According to EULAs I encounter, all liability is in the court of

    > the user. I mean… from EULA of my VS2003: "MICROSOFT

    > AND ITS SUPPLIERS PROVIDE THE SOFTWARE AND SUPPORT

    > SERVICES (IF ANY) AS IS AND WITH ALL FAULTS, AND

    > HEREBY DISCLAIM ALL OTHER WARRANTIES yada-yada-yada".

    > I read that as "no warranty wrt to how the software works,

    > period".

    Yeah, but other parts of asserted EULAs contain assertions of 90-day warranties, even though no asserted party to those EULAs honours that 90-day warranty.  I read that as a fake warranty.  Recently I read rumours that some new products have fake 1-year warranties instead of fake 90-day warranties.

    Tuesday, June 19, 2007 10:00 AM by Stuart Ballard

    > How about "liability capped at the price you paid for the

    > software/support, plus legal fees"?

    In my case if it were liability capped at the price I paid for the software, plus transportation expenses going to hardware vendors in tracking down the bugs (i.e. no legal fees in my case), that would be fine with me.  I think I wouldn’t hate a company that would honour its warranties in such a way.

    Tuesday, June 19, 2007 11:21 AM by Dave

    > examples where a company or open source project was found

    > liable for non-malicious code problems?

    Does code include firmware?  For example firmware in floppy disk drives?  For example a case where there weren’t even any known examples of data loss but only the theoretical possibility was shown?

    Um, maybe no, code doesn’t include firmware.  Because for firmware the answer was a huge "yes" and for software maybe the answer is still "no".

  29. Anonymous says:

    Schneier’s system is also rife for abuse.  How do you attach blame for misconfiguration?  Say I want to take down a big, evil software corporation…  Well, I install one of their servers (in Europe, preferably) and misconfigure it slightly.  Then I get my friends in Russia to hack the server (or I let them do it) and me and my lawyer friends get on SoftCo’s back in a European court.  We’d have lawyers trying to decide what proper security is and then we’re done for.

    But I am not a lawyer, and really should not be talking about legalisms.

  30. Anonymous says:

    Just one question: If DRM would really be passive, then why is the DRM code inseparably integrated into the kernel, is called from time to time and heavily interacts with other system components? And in fact every DRM-crippled file can trigger arbitrary actions with SYSTEM rights. Mr. Gutmann has been overstating some details, but his conclusions are pretty much correct, since they represent what the implementation looks like and can supposedly do.

  31. anonymous: Why do you believe that DRM code is "inseparably integrated into the kernel, is called from time to time and heavily interacts with other system components"?

    The kernel part of DRM is implemented in a couple of drivers (ci.sys, drmk.sys), it’s not "inseparably integrated".

    Could you please give me your reference to the assertion: "every DRM-crippled file can trigger arbitrary actions with SYSTEM rights"?  That’s a huge security hole in Windows and we absolutely take stuff like that VERY seriously.  

    Have you actually analyzed the implementation or are you simply repeating what you read on /.? Or are you thinking about things like the Sony "rootkit" DRM system?  One of the reasons that Microsoft implemented DRM in Windows was to provide a reliable DRM solution that provided a robust alternative to 3rd party solutions that weren’t always as high quality as the built-in solution.

  32. Anonymous says:

    It is not just in the drivers anymore, it is part of the kernel now as well. And is inseparable, since it’s part of the kernel and you can’t replace the drivers with dummy stubs anymore.

    How DRM-crippled files can do whatever they want? Well, just consider what functionalities are offered via the DRM license scheme. Shutting of various subsystems, deleting arbitrary files, loading arbitrary modules. Sure this is a security issue, but it’s not that Microsoft would have ever taken that seriously since the release of Windows Vista.

    Beside that, what’s about the localization feature? You can still put a desktop.ini anywhere with the content:

    [LocalizedFilenames]

    malware.exe=foobar.jpg

    and fool around the user with spoofed filenames.

    What about MSIE? It’s still there and integrated into the shell!

    For your convience: Yes, I have analyzed the implementation thoroughly.

    And please, cue your DRM jokes. DRM was put there to enforce restrictions against the user without his consent (and without legal liability, even though this has to be decided yet).

  33. The wierd thing is that the DRM people at Microsoft seem to believe that every one of your assertions regarding DRM is false (I just asked them, because some of your assertions involve significant security vulnerabilities).  I’m having a real hard time accepting that you’ve actually done the research, especially since you’re hiding behind an anonymous ID and aren’t willing to quote where your information source is.

    IE’s not integrated into anything – sure you can use the shell to launch IE if you specify a URL in the address bar.  You can do the same thing with FF if you specify it as the default web browser (I just tried this).  You’re right that Windows comes with an HTML rendering engine and that you can’t replace that HTML rendering engine (you can however install your own rendering engine and use it by default).  That’s because the developer community that writes applications on top of our platforms has requested that Windows have an HTML rendering engine built-into the operating system.

    I can’t speak to the localizedfilename feature, I’m not a shell developer.

  34. Anonymous says:

    Strange enough the official documentation about DRM even states some of the internas of DRM, f.e. how Protected Media Path, when being requested, forces the shutdown of any non-compliant sound driver.

    Then again, of course MSIE is deeply integrated within the Explorer shell. What do you think where the single-click link stuff, the thumbnails etc. come from? Why it’s called ShellDocView control? Or what the desktop.htt does? Hell, it even extracts HTML from image metadata. Just one little bug in IE, and just viewing a set of files in Explorer can trigger arbitrary code, and of course MSIE is full of years-old unpatched vulnerabilities.

  35. Dean Harding says:

    Methinks "anonymous" (if that *is* his real name) is just making stuff up as he goes along.

    That desktop.ini thing is pretty stupid to begin with. I mean, if you can already read/write the desktop.ini file it means you’re already executing code, right? So what does adding that stuff to desktop.ini give you in addition?

  36. Anonymous says:

    > IE’s not integrated into anything

    In Vista, I believe about 99% of that.  Two examples of why I believe that much:

    (1)  Windows Update appears to operate as a Control Panel applet instead of Internet Explorer ActiveX control.

    (2)  The boot logo doesn’t boast that monopoly power got every browser other than Internet Explorer booted out of OEM distributions.

    One example of why I don’t believe more than 99%:

    My Quickstart toolbar still gets to contain shortcuts that I want it to contain.

    > I can’t speak to the localizedfilename feature

    But you could test it easily.  I think[*] you can just edit that file with Notepad.  I think the only possible effect is, as Anonymous said, to spoof the user.  We’ve seen that repetitions of spoofs like loveletterforyou.txt.vbs still aren’t security issues and still don’t need any reconsideration of default settings in Vista and even in server OSes, so don’t waste time experimenting unless you want to experiment.

    [* I’ve viewed it in Notepad but haven’t experimented with changing it.]

  37. IMHO the desktop.ini file thingy could actually be interesting.  RSnake gave a great talk at BlueHat called "A death of 1000 cuts" where he discussed how small vulnerabilities can lead to exploitation.

    IMHO, the classic example of this is Liu Die Yu’s 6 step IE compromise (http://archive.cert.uni-stuttgart.de/bugtraq/2003/11/msg00029.html), which took 6 different moderate class vulnerabilities (none of which alone could be used to gain system access) and combined them together in such a way as to gain system access.

    So the desktop.ini file COULD be used as a stepping stone to gaining system access.

  38. anonymous: the PMP is actually an area that I’m VERY familiar with.

    And this code isn’t new – drmk.sys existed on XP and it did exactly the same thing in XP as it does in Vista – it scanned the system looking for unsigned drivers and reported their presence to the application rendering audio which was allowed to make a policy decision based on the presence of unsigned drivers in the rendering path.

    Nothing has changed in that area for Vista (there were other parts of the DRM system that did change for Vista, the introduction of protected processes, for example, but that part didn’t change).

    The S/PDIF cutout was also in XP (including the USB exception which is still in Vista (USB S/PDIF devices don’t have to disable their S/PDIF output when protected content is rendered – go figure that one out).

  39. Dean Harding says:

    > So the desktop.ini file COULD be used as a stepping stone to gaining system access.

    Possibly, I suppose. But like I said, if you can already read/write a desktop.ini file, you don’t need to disguise an exe as a jpg or whatever. Unless you’ve *already* compromised the system and are just leaving your "picture" as a surprise 🙂

    A possible fix would be to simply not allow you to change the extension of a file using desktop.ini.

    > My Quickstart toolbar still gets to contain shortcuts that I want it to contain.

    If you mean "shortcuts to internet locations" then that has nothing to do with Internet Explorer. You could just as easily have those shortcuts launch in Firefox using the "set program and access defaults" thingy… if you mean something else, please elaborate.

  40. Dean: I think I found tomorrows post.

  41. Anonymous says:

    Thursday, June 28, 2007 1:00 AM by Dean Harding

    >> My Quickstart toolbar still gets to contain shortcuts that I

    >> want it to contain.

    >

    > If you mean "shortcuts to internet locations"

    I mean shortcuts to programs that I want to invoke.  Theoretically it could mean shortcuts to internet locations, though I never thought of using up valuable real estate in the task bar for such a purpose.

    Did you notice the folder names that you traverse in order to get to those shortcuts?  Do you think I’m going to waste time experimenting to see if they’ll still work after renaming one of the folders to "Netscape Navigator"?  Do you think maybe someone other than a monopoly set that folder name because that would be the real way to get Netscape kicked out of preinstalls when OEMs wouldn’t cave in to financial bullying?

    Anyway, I do find the Quickstart toolbar convenient, I do use it, and hold my nose while traversing directories to get there.

  42. Anonymous says:

    "Did you notice the folder names that you traverse in order to get to those shortcuts?  Do you think I’m going to waste time experimenting to see if they’ll still work after renaming one of the folders to "Netscape Navigator"?  Do you think maybe someone other than a monopoly set that folder name because that would be the real way to get Netscape kicked out of preinstalls when OEMs wouldn’t cave in to financial bullying?"

    I *think* QuickLaunch was originally added by the IE4 upgrades to the shell, someone please feel free to correct me if that’s wrong 🙂 But, if that’s the case, then the reason that the path contains "Internet Explorer" is one near and dear to Microsofts heart, back-compat…

  43. Anonymous says:

    For writing a desktop.ini, you don’t need to run any program. Just pack it up in a ZIP file together with the malware and let the user extract it. Voilà, the malware and the desktop.ini end up in the same folder.

    Even further, you can name the folder as Foldername.{GUID} whereas the GUID is a reserved one of the shell namespace, f.e. the MyDocs GUID. In this case, independent of your settings, Windows Vista will definitely load the desktop.ini and act accordingly.

    Or what if the user downloads multiple files with a download manager? He won’t even see a redirect to the different filename "desktop.ini" instead of "some_cool_stuff.zip". He also downloads the malware, and then, since they end up in the same folder, the trick works again.

    As for PMP: According to my analysis, the application is also providing a policy (TagDRMRights struct) which then enforces how drmk.sys forwards data and signals the required commands to DRMed driver, or the shutdown of non-acceptable drivers to the ks.sys subsystem.

    At any rate, on Windows XP you can safely replace drmk.sys with a dummy module and remove the rest of the DRM subsystem. Now, how does this work on Windows Vista? I’d say not at all.