| Date: | March 14, 2006 / year-entry #94 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060314-02/?p=31923 |
| Comments: | 45 |
| Summary: | On MSDN, there's a series of articles on the top ten things to do to make your application a Vista application. The series began last December, and just this month, they covered a topic dear to my heart: Application compatibility. [Update 2pm: If you have feedback about these articles, posting that feedback here won't accomplish... |
On MSDN, there's a series of articles on the top ten things to do to make your application a Vista application. The series began last December, and just this month, they covered a topic dear to my heart: Application compatibility. [Update 2pm: If you have feedback about these articles, posting that feedback here won't accomplish much since I am not the author of those articles.] |
Comments (45)
Comments are closed. |
You said in a prior artical Win16 support was impossible on Win64. I was wondering why this is seeing as how the NT4 for Alpha platform had a full DOS/Win16 VM that used emulation. Was this not written in C and therefor not portable to Win64 on x86-64? I understand that on NT for x86 the ntvdm used a thunking system that is not possible in LP mode on the x86-64 but I have yet to see someone address why a full emulation package is not possilbe. Dos/Win3.1 apps ran quite well under the emulation on Alpha.
I don’t recall ever saying that it was impossible.
Steven, handles on Win64 have 29 significative bits, as opposed to 13 on Win32, so a lot of code would have to be added to what practically is a dead component to emulate the handle table. And the changes would have to be tested on all mixed 16/32 bit applications out there
you want 16 bit emulation? Install VMWare and run DOS in it :-)
Oh, and the signed driver requirement is such a BAD idea. There should be a way to disable it, for example creating a obscure registry key (that no application has privileges to do by default). So only somebody who knows what he’s doind can install them, but a evil installer can’t trick the user into doing it.
I can already see "rogue" driver installers forcing a boot from CD, using an external NTFS driver to mount the volume and then patch the kernel to disable it. Ugh.
And anyway, it’s not like code singing serves any purpose: wait until MS is tricked into singing a general-purpose loader (or a load-protection cracker!), and that’s it. There was a post here about how graphic card companies did domething similar.
Why isn’t there a per-user Program Files directory in Vista or any prior version of Windows?
This is a question I have not seen addressed in any Microsoft documentation or any blogs. Now, I think any program that wants to let non-admin users install has to invent its own per-user Program Files directory, and each program chooses a different location, so program files get scattered about the user’s hard drive. I’m wondering why Microsoft did not allocate a proper directory for per-user Program Files, discoverable via SHGetSpecialFolderPath()?
I like driver signing. Everytime my system has become unstable, it was because I recently installed an unsigned driver. System Restore saved the day.
If you want to complain about the articles, go complain to the people who wrote the articles. I didn’t write them.
C++ guy: For me it is the opposite: Whenever I install a signed driver for my (on-board) audio, my machine crashes. I have to install the non-signed for it to work.
Thus, just because YOU like driver signing (because it has shown to be the best solution in YOUR case) does not mean that this is the best solution for everyone else, does it? I don’t like Microsoft incapacitating me, the user.
"Thus, just because YOU like driver signing (because it has shown to be the best solution in YOUR case) does not mean that this is the best solution for everyone else, does it?"
Wow, did you seriously extrapolate him saying "I like driver signing" (that’s an exact quote) to "this is the best solution for everyone else"?
HA HA HA you’re insane.
It is my understanding that the drivers must be signed, but not necessarily by Microsoft. You should even be able to sign your own drivers.
The driver signing in Vista is not an upgraded WHQL. It’s about DRM rather than quality. Please learn more about this topic before commenting further.
I hope Vista’s installer will let you do less half-assed customizing at installation time instead of making me keep burning slipstreamed cds like nLite.
I’m going with Gabe – drivers have to be signed but that’s it. A digital signature does not require you to pay anyone (and you bet there’s gonna be installers adding their own CA certs to your trusted CA list). That will not stop any open source or free drivers from being installed, just download openssl, create your own CA and certificate and sign away.
I was instantly converted to the "all drivers should be signed" camp when I saw Optyx’s "Kernel Intrusion System" (KIS) at Defcon 9. Regardless of what operating system you run, do you honestly feel safe loading drivers into your kernel knowing that may have been maliciously modified since the last time you booted?
Regarding signed drivers: So, uh, what’s the point? If it’s that easy to sign drivers, then what’s to stop $random_cracker from signing his file-hiding rootkit and distributing it? Or what’s to stop $random_cracker from modifying one of your existing drivers, re-signing the modified copy (with his own cert), and going on his merry way?
(Not that I’m saying requiring a signed driver is a good thing. I use Ethereal (=WinPcap, an unsigned Winsock protocol driver) almost every day, and I would hate to lose that capability. Netmon just plain doesn’t cut it.)
David Hunt: No, I don’t feel safe doing that, on either Windows or Linux. But yet, I trust Linux’s permission scheme to the point where I know nobody could have changed anything under /lib/modules without physical access to the machine; I don’t trust Windows’ permission scheme on system32drivers given the state of users. Nobody (well, almost nobody) runs Linux as root. If nobody ran a Windows machine as an admin, nobody would (probably) have permission to change any of the files in system32drivers, so this problem wouldn’t exist here either.
In the end, I’m not sure that it’s signing you want, I think it’s hashing plus a secured central list of hash values.
"The majority of Windows-based executables are protected by WRP"
So, which ones aren’t? Why?
C++ Guy: "Why isn’t there a per-user Program Files directory in Vista or any prior version of Windows?"
There is, in Vista. I was at a Vista preview presentation last night and the presenter stated that applications could be installed into a user’s own program files folder. This was so they could install programs without admin privileges (installing is apparently one of the main reasons people run with higher privileges than they ought.)
On the other hand, he implied (this is me guessing from what he said) that it was transparently mapped, so a user wouldn’t realise they weren’t using the ‘c:Program Files’ directory… I don’t know for sure that this is the case or what the mechanism for this is, but it sounds a bit ugly.
Oh please. Who needs signing anyway? Lots of unsigned drivers get themselves installed excellently, they just use some sort of FindWindow/PostMessage combination to click away the "installing unsigned driver" warning window! I’ll probably have to do this myself, although for legitimate (even if not foreseen by MS developers) reasons.
I agree that requiring driver signing is a terrible idea and is only done so that microsoft can collect royalties for Windows support.
* As shown before with graphics drivers, driver signing provides NO indication of driver quality.
* It will prevent the installation of open source drivers, like WinPCap and TUN/TAP and others.
* When the next Windows is released, Vista drivers will be immediately dropped so manufacturers do not have to pay to certify two sets of drivers.
* It will slow down driver release cycles (==longer to fix bugs) as it will probably take several weeks for a driver to be certified, manufacturers will not want to drivers too often to save costs and they will want to be certian about a driver before submitting it.
* WinHelp and HTML Help (.chm) files support: Windows Vista introduces a new help model called Windows Help. All applications need to update their help documentation to the new model for Windows Vista versions. Older formats will continue to be supported for legacy applications through a downloadable WinHelp component, which will not be in Windows Vista by default.
WTF?! No, really, WTF? Now what? Shipping two help files?
* An opportunity for a very secure design.
"opportunity"?
* The user data is now stored in users%username%
Will be localized like "Program Files" was? "Documents and Settings" was not. And BTW what’s up with the hardcoded path "Application DataMicrosoftCD Burning"? "Application Data" should be localized.
* low-integrity locations, such as (…) the Windows Temporary Files folders
This is /Temp/ ? This would allow attacks against other apps.
* Windows Resource Protection
I hope there’s a way to disable this. Like in XP, where you can abuse the race-condition style protection by attacking at the same time the file and its copy on /dllcache/.
* Users can right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode to allow the application to work as it did on Windows XP.
Does this means "with full privileges"? Ugh :'( So you have to choose between LUA and lie-the-stupid-application-so-it’ll-work?
C++ guy: Ok, but wouldn’t you like to have a choice? Right now, I agree it doesn’t work because it’s too easy to install unsigned drivers, but hiding this from the UI should be a good compromise. Otherwise, we’re back to binary patching, just like with the retarded 10 half-open connection limit in SP2.
(from the article) "By following the Windows Vista User Experience Guidelines, developers can provide their users with a consistent and predictable user experience."
Someone *please* forward this to the Office 2007 design team!
"Older formats will continue to be supported for legacy applications through a downloadable WinHelp component, which will not be in Windows Vista by default."
Cute. That’ll help application compatability for older applications – their help files won’t work unless the end user knows to download a special component, which won’t be mentioned for applications that were originally written before this particular document was published. Really, why the hell are they making it an optional "downloadable" component? Aren’t they aware that everyone upgrading will probably want to keep a whole pile of old applications?
"All kernel mode printer drivers will be blocked from loading on Windows Vista"
Aka, in the interests of the mythical backwards "compatability", don’t upgrade to Vista until after you check whether or not you can continue to use your printer.
"While most of the applications from earlier versions of Windows should not be impacted by VDDM, some risks include: DX Games compatibility, resulting in DX run-time or IHV driver or core graphics stack issues."
Cool, home users better make sure they keep a backup of their previous OS version, just in case. (To be fair, I’ve played that game before, so I’m not completely shocked.)
Btw, no point to complaining to the article authors – it’s not as if they’ll actually care or be able to make moderately significant changes that invalidate all the advertising that’s already been done. I’m just complaining about the people spreading the myth that Microsoft cares about not breaking old stuff. I used to actually believe that, but based on this bit, I’m a little more sceptical.
I really love the idea of Windows getting a major overhaul with all the old application compatability junk and brain-dead APIs being removed, but as soon as that’s done I’m going to bitch about all the things being broken. I guess it’s true – Microsoft can’t win. ;)
(Just to be fair, though, mandatory access control isn’t a problem, if your admin gives you wide-ranging access. That detail is entirely in the realm of office politics, not technology. But still, I should be *allowed* to install whatever I want, even if I first have to disable the security protection.)
But hey, it’s not all bad: at least they’re finally going to kill off OpenGL on Windows. That’ll be a great step forward, right?
Jerry Pisk: "I’m going with Gabe – drivers have to be signed but that’s it. A digital signature does not require you to pay anyone (and you bet there’s gonna be installers adding their own CA certs to your trusted CA list). That will not stop any open source or free drivers from being installed, just download openssl, create your own CA and certificate and sign away."
That’s not true, unfortunately. While it’s true that the mandatory driver signing doesn’t mean WHQL signing, you can’t just use any CA to sign the drivers. In fact, MS requires a Verisign class 3 certificate (which is about $500 per year), you can’t use any other CA at all, it *must* be Verisign.
Are you serious about that WinHelp and .chm files???
Whoever invented this is an idiot!
There are millions of applications with classic .hlp files, so now it won’t work becouse some jerk decided all people should re-work their help files, move to Vista and dont look back? This is so wrong.
But we already know this, for example a few new apis used by Microsoft Office to prevent it from running under older Windows versions.
Another thing:
"D3DRM. DirectX will be the only supported graphics package for Windows Vista."
so does it mean OpenGL won’t work??? Suuuuuuuuure, who needs this…
I’d rather install Linux !!!!
Raymond, you said application compatibility is close to your heart, but it seems your company doesn’t care about compatibility with previous versions of Windows.
"I’m just complaining about the people spreading the myth that Microsoft cares about not breaking old stuff."
Ah-ah! Joel wrote about this back in 2004. And he mentioned Raymond Chen too:
http://www.joelonsoftware.com/articles/APIWar.html
Makes for a very interesting reading on the old and the new school at Microsoft.
I just walked back into office and 1 floor below me they’re trying to get Windows 98 working again (installing a graphics driver). (And there’s a beige desktop model PowerMac G3 with Mac OS 9.2 in the corner, but it’s not doing much)
I’m glad that some items on the list, like supporting FUS and IPv6(-only) are already done in my programs. Many other applications aren’t even fully Windows XP compatible though (yet are marketed as such). Even software from huge companys like NAI fail to work properly. Just try installing an application, logging out and back in as a normal user, or accepting to reboot and then log in as a normal user, or just log out and back in as an administrator without rebooting. Even MSconfig doesn’t seem to recognise this. And there are still applications that aren’t aware of user profiles (and always place shortcuts in the current users menu instead of all users).
Driver signing is pointless. What is required is protection on the registry such that drivers can *only* get installed via the proper windows API. Such that drivers – or any kernel mode components – *cannot* be silently installed. For eg. by by CD autorun apps, or even game installers that include perverted DRM systems like StarForce.
Plus, It really bugs me that I cannot even install drivers for my Creative LAbs sound card without running an install.exe.
I *should* just be able to point the new hardware has been discovered wizard at a directory with an INF file for any hardware I plug in at all. But no. Too many hardware vendors feel that, in addition to the basic driver – they can push the installation of other "value added" crap. I am really tired of installing more than I need.
Lots of people still use x32 and will for quite a long time yet.
Sure, and that’s why 32-bit drivers do not have the signing requirement. So the drivers work on Vista, but you still have the old "post a message to the unsigned driver warning window" problem. (Assuming that has not been blocked in the same way as the LUA/UAC elevation prompts block it…)
But going forward (on 64-bit), this trick won’t be possible any more, which is why establishing the x64 driver signing requirement right now is a good thing.
Dan: Not exactly true. Call these APIs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/certopensystemstore.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/certaddencodedcertificatetostore.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/certclosestore.asp
just before installing your driver, to add your cert to a certain store. You can probably use the SPC store, but you might have to use ROOT instead. I’m not sure what store(s) Vista is going to check when looking for the root cert.
I don’t know about security on these calls; it may be that only local admins can open the machine’s SPC or ROOT stores. (Yet another reason to not do your everyday tasks as a local admin.)
BryanK: Sure, but for a bad guy to do that, he already needs to be running code on your machine with enough privileges (admin) to add a cert to the root store. If that’s the case, you’re already done, and loading the actual driver is somewhat irrelevant. Driver signing by itself cannot prevent all indirect attack paths like this; they are covered better by other features like LUA (as you said…don’t run as admin)
Actually, I’m pretty sure that installing a new driver also requires admin privileges. ;-)
Of course installing a driver requires admin privileges. What I was explaining was the answer to this question you asked:
what’s to stop $random_cracker from modifying one of your existing drivers, re-signing the modified copy (with his own cert), and going on his merry way?
What’s stopping him is that "his own cert" is not installed in your trusted root store. He now has the extra hurdle of getting you to somehow add his cert to your store, or else his driver won’t load. Of course, he can do this himself if he can get you to run some other code he gives you which will add the cert to the store. But that’s a totally separate issue. Just by itself, the driver can’t be loaded.
Sure it doesn’t solve all indirect attack scenarios, nothing does, but it raises the bar a little. Now he not only has to get you the malicious driver, he also has to get you to install his cert or run his code that installs it.
And I should clarify: if by "modifying one of your existing drivers" you meant that he gets on your machine and twiddles with a driver installed there, this is moot, because if he can do that he already has admin access to your machine.
If you instead meant that he takes some legitimate driver (say, an nVidia display driver), adds malicious code to it, and gives it to you to trick you into installing it because you think it’s an nVidia driver…this is exactly the attack scenario that is prevented, assuming just the driver file is involved.
BryanK: It’s easy to sign drivers, but not easy to get machine owners to install your certificate in their chain of trust. The driver has to be signed and the certificate needs to chain up to a trusted root, or it won’t load.
vince: Driver signing isn’t about preventing someone who owns your box from loading drivers; that’s impossible. But an admin has to get drivers from *somewhere* first, and how does he know who created the driver, and whether it has been tampered with? If the driver is signed, he knows whether it is from a source he trusts or not, and that it hasn’t been tampered with by someone else who is trying to get him to install it.
A Tykhyy: A signed driver is *required* on x64. There is no "unsigned driver warning" window to which you can post a message.
Just know it that MSDN has an article detailing the ten things to do to make your application a Vista…
"for users to figure out who they trust".
http://blogs.msdn.com/oldnewthing/archive/2005/12/27/508688.aspx
A Tykhyy: You won’t be able to click away the "installing an unsigned driver" dialog on Windows Vista; there will be no such dialog. Unsigned drivers will not install or load.
Ah, OK, I get it now. (Took me long enough…)
Yes, that sounds about right: it raises the bar a little. The only remaining question is then whether I trust Verisign to identify various code signing cert requesters to a sufficient level (see, for instance, http://isc.sans.org/diary.php?storyid=1118 — Equifax/GeoTrust don’t qualify anymore, IMO). How do I know what Verisign *really* does (as opposed to what their policies say they do)?
How do I know $random_cracker can’t get a cert from Verisign that claims they’re "nvidia" (however the code-signing certs are supposed to do that), except with a different Unicode homograph for one of the ‘a’ characters (e.g. something out of the Cyrillic alphabet)? How do I know they didn’t register with Verisign for a cert with a completely different name than "nvidia", but one that would still be associated with them in most users’ minds? (I’m not sure what that might be though.)
What I think we really need, instead of random people (Microsoft, other browser makers, etc.) deciding which certification authorities are trusted, is for users to figure out who they trust. (And for company network admins to be able to do the same thing inside their domain.) A link I found on an earlier post in this blog seems appropriate: https://www.financialcryptography.com/mt/archives/000629.html
Raymond:
> "for users to figure out who they trust".
>
> http://blogs.msdn.com/oldnewthing/archive/2005/12/27/508688.aspx
Yes, that’s the blog entry where I found the link to the article I posted (at Financial Cryptography).
Most users are clueless, as you basically said. But the 0.9% that *do* know what’s going on, and which authorities are trustworthy (for instance "not Equifax/GeoTrust") will inform the 9% (the "interested amateurs") as they ask about different authorities, who will in turn inform the 90% (the masses of clueless people) as *they* in turn ask. But as the article said, it has to be "pulled", it can’t be pushed.
Open governance can work, as long as the 0.9% group exists, and as long as the 9% group knows who to ask.
But even if we accept the argument that users won’t know who to trust (and I don’t, but just for the sake of argument here): Who’s to say that Microsoft’s choice is correct? Why is Verisign automatically trustworthy? Presumably it’s because of their policies, but how do you know they always follow them? (Yet again, see the Equifax/GeoTrust article.) What happens if they stop following them some time in the future?
PingBack from http://blogs.msdn.com/oldnewthing/archive/2006/08/18/705957.aspx