Slashdot Mirror

Get Filemon and Regmon from sysinternals.

Set the filter to highlight ACCESS_DENIED (in Filemon) and ACCDND (? I think) (in Regmon). Run any program you want, and see what it does wrong.

Some programs are irreperably stupid. Others like trillian are relatively isolated.

The way I run trillian is that I set the "users/" directory ACL to Users rw-. And you will be able to run it as non admin.

I run SecureCRT and VShell too, I don't know for earlier version, but for later versions they run perfectly fine too. If you have issues, do the above method, and find out what they are trying to access.

Btw, if you get access denied's in the registry, you can change the ACL for a key as well using regedt32.exe in Win NT/2k, and regedit.exe in WinXP.

All part of sensible configuration. Granted, normal users wouldn't be able to figure this out, but normal users wouldn't use SecureCRT either.

You could always install the BSOD screensaver and set is as the default. I did this to my manager.

Hmm. I guess I don't consider myself a guru, but I know more than any of my personal friends.

Although this does still seem to exist somewhat, I think it's taken a real drop since Win2k and XP. I'm a sysadmin for a large Win2k network, and from what I can see, the servers stay happy until they are taken down.

We had the most problems when people were on 95/98. With the ability to install every type of software you can imagine (not my call, I was a grunt back then) the machines grind to an agonizing crawl. After a wipe and reinstall, they become speedy quick. Perhaps it would still happen on Win2k and XP, but I don't let users install software now. The machines do fine.

I really think that the root of all those problems is shitty software. Seems that most commercial software you install nowadays wants a bit of your screen and processor real-estate by installing all sorts of icons and background programs. Quicktime? Realplayer? Winzip?!? Wtf?

Check where programs run on startup. And that means registry digging too. Check HKLM\Software\Microsoft\Windows\CurrentVersion\Run . Check for hooks into explorer.exe in the registry, though that usually means your box is compromised. Legacy programs can still put stuff in win.ini and system.ini. Check the Windows Start Menu startup folder.

Check running services in the MMC snap-in. Run services.msc to see them. See something you don't recognize? Track it down. Look at what processes are running for clues. See a process that you don't recognize? Find out what it is. I use Process Explorer from Sysinternals, a nice little free app. That running process that doesn't need to be there is stealing from you. Stealing your cycles and time.

I probably forgot some things, but there are lots of places to "startup" things in Windows. And be careful. One wrong keystroke with this stuff and you can kill your system.

My machine that I use for work is solid, has been for years. I will usually get uptimes measured in weeks with no problems. Stupid security patches.

What other WordStar-like control-key command editors are there? I find that not having to take my hands off the home row of keys saves about 15% of editing time. I also find that Vi (Vim) is too complicated and quirky to teach my customers.

I would like to see the authors of the Scintilla editor make control-key commands available, perhaps with a way to change modes between control-key commands and the present shortcut key commands.

To use the control-key commands, the control key should be just to the left of the A key. This program converts the Caps Lock key to a Control key: Ctrl2cap.

Here are a few Control-key editing commands. Anyone who is interested in this subject should contact me for the complete list. (The list formatting is damaged by Slashdot.)


Some Control-Key Editor Commands (Save about 15% of editing time.)

Name of Command Primary Sequence Secondary Sequence

Character left <Left> <^S>
Character right <Right> <^D>
Word left <^Left> <^A>
Word right <^Right> <^F>
Cursor to left side <Home> <^Q><^S>
Cursor to right side <End> <^Q><^D>
Line up <Up> <^E>
Line down <Down> <^X>
Scroll up <^W>
Scroll down <^Z>
Page up <PgUp> <^R>
Page down <PgDn> <^C>

Top of file <^PgUp> <^Q><^R>
End of file <^PgDn> <^Q><^C>
Top of window <^Home> <^Q><^E>
Bottom of window <^End> <^Q><^X>
Up to equal indent <^J><^B>
Down to equal indent <^J><^E>
Go to line <^J><^L>
Go to column <^J><^C>
Go to byte <^J><^A>
Previous cursor position <^Q><^P>
Match braces forward <^Q><^[>
Match braces backward <^Q><^]>

New line <Enter>
Insert line <^N>
Insert control char <^P>
Delete current character <Del> <^G>
Delete left character <BkSp> <^BkSp>
Delete right word <^T>
Delete line right <^Q><^Y>
Delete line <^Y>

reading this article gave me an initial knee-jerk reaction of checking it out...

Read the next paragraph a-la Monty Python skit:

But all the clues pointed that in fact, there was no hole on my computer. The announcement on Microsoft site said the flaw had been disclosed on the 10th. The "support" bullet said: a patch will be made available within 24 hours... and my windows update didn't warn me of anything.

So I took out my handy "psinfo -h" and found the following atrocity:

OS Hot Fix Installed
...
KB824146 9/10/2003
...

A full 8 days ago.

For those who couldn't figure out the skit, it's the Ralph Melish skit where absolutely nothing happens.

A link to FileMon for anyone who wants to do a similar test.

I noticed the same on my Linksys BEFW11S4. I wasn't humored by this at all.

In the end, I decided to put a static IP that wasn't being used by any devices on my network as the DMZ address. Now all requests from outside to ports 135, 137, 139, 445, etc. are neatly and conveniently routed off to a black hole, as verified by LinkLogger, nmap from outside my network and the occasional glancing at netstat -a or TCPView to check my connections.

Granted, this is a pain if you need to change it for gaming or IRC, but it's better than being owned by the random script kiddie.

Run WinObj.
Find the symlink to the drive.
Change the ACL.

11. The user shall have the right to view the source code on demand.

Imagine if you were fined whenever someone breaks into your house or car -- just because you didn't install better locks/better alarms/whatever doesn't mean that it's always your fault.

But you are fined... even if it isn't your fault sometimes. Someone breaks into your house or car. You file a claim with your insurance company. A bill or two later, you find that your rates have gone up.

As far as a tool to install, the stuff at SysInternals which let you attach remotely to a machine and push one of the fixit scripts are administrative dreams.

You can just call win32 function OutputDebugString (or the TRACE macro, but that may just be MFC) and the debug messages will show up in Visual Studio's debug window. DebugView from Sysinternals will also show debug messages.

Well, Here's one for Win9x/NT/2K/XP.

If a system has been compromised, then you can't afford not to take it down.

Errr... not immediately, no.

Say you've just discovered that a box is compromised (e.g. you noticed an internal box portscanning your local network), you'd immediately take it down?? The whole point of forensics is to gather as much evidence as possible from the compromised machine, and shutting the box down or disconnecting it from the network means losing vital information, so you better be sure you've got as much evidence as possible before powering off. While there is always a fine balance in deciding whether or not to switch off (e.g. do I leave this box up an extra few minutes while I gather more evidence, after having discovered that the box is running a ton of SQL queries against the DB server), it should be carefully considered rather than a knee-jerk "pull the plug" approach.

Besides, the original parent poster seemed to have missed the point that the forensic analysis shouldn't be done from the compromised box; run netcat or cryptcat (from read-only media such as a CD) on it and pipe the shell to the secure forensics box (running LASL 0.4a for instance), then gather your evidence here. Depending on the compromised OS you'll need a variety of binaries on the CD to put in the suspect box, for instance the excellent PS tools are a must for Windows auditing.

For those interested in forensics it might be worth reading a paper linked off the front of SecurityFocus at the moment: Maintaining System Integrity During Forensics. While it's not really intended as an introduction it does cover the main points pretty well, so would be worth a read if you're curious.

What about using this plus SSH ?

was the Northgate Computer Systems Omnikey.

For those of us who learned to program before the
advent of the IBM PC, they have the "correct" layout
(the layout for which and with which vi was developed)
with the control key just to the left of the 'a', As God Intended)*
Buckling spring, Alps switches, removable keycaps, steel base,
fully programmable key assignments, DIP switches for common
configuration options. Indispensible and indestructible.

I have two, and they continue to work perfectly after
lo these many years, and there's a brisk market for them
on ebay (lots of old hackers treasure them).

But they're no longer made.

Fortunately, CTI makes a close copy. The Avant Stellar
is by all accounts superb, and bears the Tibor Polgar seal of approval.
Buy a couple while they're still made, and you're set for life.

The Customizer seems to be similar, but I have no experience with this keyboard.

* and if you're one of those people like me who has spent the
last twenty years cursing IBM for screwing up the layout of
ASCII keyboards for all time by fiddling with the the
One True Layout (with the control key to the left of the 'a'),
then you may be happy to know about the superb small program
ctrl2cap from Systems Internals, which makes the
usless never-to-be-sufficiently-damned caps lock key
into a control key. Tiny, slick, sophisticated, open source, free.
Check it out.

>> Using a program (which i'd strongly reccomend to you if i could remember what/where it was)

Fortunately, I can. ;)

One tool that does what you describe is called "Process Explorer" and is available from SysInternals. Free.

The trojan that you found sounds like one of the many mIRC replacement programs that are used for botting and DDoS attacks. We found one on our network and were able to trace it's introduction back to a website. It used an exploit in IE that allows the installation of applications without the approval or awareness of the user.

Just one more reason to not allow the use of IE in the workplace...

Worse than that, THG can't even get their facts straight. For example, when discussing fsutil.exe on page 4, the caption of the picture calls it a DOS app (it's not) and say it's from Sysinternals (perhaps they meant ntfsinfo, like the picture shows), yet the article text properly calls fsutil a "command line utility" (which it is) from Microsoft (which it is). While they do mention that it works on XP and not Windows 2000, they don't bother to mention that it's also available on Windows Server 2003, and that it's a system utility that's installed with the OS (c:\win[dows|nt]\system32\fsutil.exe). And just to add insult to injury, the "fsutil fsinfo" command they suggest you run is not quite correct. You need something more like "fsutil fsinfo ntfsinfo c:". "fsutil fsinfo" by itself just gives you another help screen, and not "scads of fascinating statistical information on the file system, volume and MFT."

All this article does is reinforce my dislike for Tom's Hardware Guide, and gives me ammunition I can use to convince others that THG is crap, too. If you want good hardware reviews, go somewhere good like AnandTech or Sharky Extreme. Hell, you could even go to Blue's News for the daily Hardware Reviews and still get better info. (I've not once seen Blue's link to THG from the Hardware Reviews ... I wonder why?)

Worse than that, THG can't even get their facts straight. For example, when discussing fsutil.exe on page 4, the caption of the picture calls it a DOS app (it's not) and say it's from Sysinternals (perhaps they meant ntfsinfo, like the picture shows), yet the article text properly calls fsutil a "command line utility" (which it is) from Microsoft (which it is). While they do mention that it works on XP and not Windows 2000, they don't bother to mention that it's also available on Windows Server 2003, and that it's a system utility that's installed with the OS (c:\win[dows|nt]\system32\fsutil.exe). And just to add insult to injury, the "fsutil fsinfo" command they suggest you run is not quite correct. You need something more like "fsutil fsinfo ntfsinfo c:". "fsutil fsinfo" by itself just gives you another help screen, and not "scads of fascinating statistical information on the file system, volume and MFT."

All this article does is reinforce my dislike for Tom's Hardware Guide, and gives me ammunition I can use to convince others that THG is crap, too. If you want good hardware reviews, go somewhere good like AnandTech or Sharky Extreme. Hell, you could even go to Blue's News for the daily Hardware Reviews and still get better info. (I've not once seen Blue's link to THG from the Hardware Reviews ... I wonder why?)

Aaaah. It said Windows. Well, that is a good question in that case. Maybe SysInternals can help. After you've got those tools install, and the Resource Kit, you have an OS that is almost usable.

Know what nine out of ten application vendors will tell you when you're having trouble with their [hard|soft]ware? "Make the user an Administrator and try again." Have you ever tried to USE an XP machine as a restricted user? How useable was it?

How is that MS's fault? If the [hard|soft]ware vendors are too lazy|incompetent to figure it out, just fire up FileMon and RegMon and adjust permissions accordingly. In most cases you install as Administrator and use as a User. I do believe XP compatible labeled software MUST be able to operate under User or Power User rights. YMMV, of course, on software designed for the security oblivious Win9x series.

Know what nine out of ten application vendors will tell you when you're having trouble with their [hard|soft]ware? "Make the user an Administrator and try again." Have you ever tried to USE an XP machine as a restricted user? How useable was it?

How is that MS's fault? If the [hard|soft]ware vendors are too lazy|incompetent to figure it out, just fire up FileMon and RegMon and adjust permissions accordingly. In most cases you install as Administrator and use as a User. I do believe XP compatible labeled software MUST be able to operate under User or Power User rights. YMMV, of course, on software designed for the security oblivious Win9x series.

Although this has nothing to do with Linux TCO vs. Windows TCO, here goes:

list of open file handles - how about Handle

list of bound ports - how about TCPView

robust scripting language - how about ActivePerl

All of the above tools are free, high quality, and easy to install/use on WIndows 2K/XP. I automatically install them along with many other tools whenever I prep a new Windows 2K/XP machine. And to think I'm not even an MCSE...

Although this has nothing to do with Linux TCO vs. Windows TCO, here goes:

list of open file handles - how about Handle

list of bound ports - how about TCPView

robust scripting language - how about ActivePerl

All of the above tools are free, high quality, and easy to install/use on WIndows 2K/XP. I automatically install them along with many other tools whenever I prep a new Windows 2K/XP machine. And to think I'm not even an MCSE...

That's an area where the Unix guys are ahead of us, because of the way they do redirection -- they can patch a file and then change the symbolic link. That's an area where we've got a problem, and we'll fix it in the near future when possible.

Is is safe to assume that MS will be implementing symbolic links on files in NTFS (real symlinks, not "shortcuts" :-)? Or is this statement just referring to how MS plans to be able to update files without having to reboot the system?

Interestingly enough, NTFS5 (on Win2K and above) already has support for a structure called Junctions. Essentially, these behave like symbolic links do in Unix, except that they can only point to directories (not to files). You can either use linkd.exe (provided in the Win2K Resource Kit) or visit Sysinterals, where they have a tool that will also create junctions. It's interesting that when MS deployed this feature, they didn't add support for symlinking to files also (granted, I don't know how NTFS works, so maybe it's not so trivial to link to files).

Also try TCPView. There's source code for the command-line version (netstatp).

If you're going to be maintaining windows boxes go to www.sysinternals.com and download EVERY single tool they have. Their stuff is awesome and extremely helpful when dealing with windows boxes. Heck, the even have an NTFS file system driver you can use to get read access to an NTFS drive from a 9x/dos boot disk.

You got in Informative?
I did some development of NT services, spooler modules and such, and I can tell you that this is not true. 1st it is difficult to kill process owned by SYSTEM account. If it is a service, you can stop it - if it is not hung. If it is a system process and it is hung/consuming much resources or is not a service, or is owned by not your account, it get's pretty resistant to such attempts. Sometimes you can attach by debugger and kill it - but not always. What works for me is Process explorer

You could always create an NTFS Boot Disk to scan a suspect system. If you want write access, you'll need a boot disk capable of writing data though. Haven't seen a free read/write solution yet...

I was thinking of a different bone of contention I have when I said that: FAT32 support, which MS never provided under NT4 right up to SP6A (I mean, the provided it under '95a/b for goodness sake!). They probably thought that it would eat into Win2k sales. I have read-only support of FAT32 with a free driver from System Internals. You can also purchase the driver with full read/write support from Wininternals.

It was a couple of years ago, but I now remember that the problem was that the (SP4-6A) NTFS5 support was half-assed - you could no longer use low level disk tools (including MS's own *cough* tools) if you had NTFS5 under NT4. And that certainly qualifies as NFG IMO.

But that's not what really pissed me off. I knew that and didn't want NTFS upgraded. What pissed me off was that Win2k did it anyway and without warning. And that is unacceptable.

• The Windows 2000 Resource Kit
• The Microsoft Script Center. Hundreds (thousands?) of VB/WS scripts you can execute from the CLI. Browse!
• The PSTools Suite from Sysinternals. Excellent for filling in any gaps in Microsoft's lineup.
• And, if all else fails, The Unix95 pack with such nice things as 'which','cp','tail','gzip','nice', ... and many more, all for the WinNT/Win2k CLI.
  
  
• Oh, and ActiveState Perl for Windows, of course :)

NT has built in defrag abilities, Diskkeeper just wrote a front end.

checkout sysinternals to be free from bullshit.

To have NT4 support FAT32, you need 3rd party software drivers like this.

Windows NT didnt support FAT32, only FAT16. Or did they add FAT32 support in a service pack?

Nope. If you wanted Windows NT with FAT32, you had to buy an upgrade to Windows 2000.

There is a driver for NT4 that supports reading and writing NTFS.

http://www.sysinternals.com/ntw2k/freeware/fat32.s html

But you can't boot from a FAT32 volume using this, and of course this isn't a Microsoft product.

steveha

BTW: Last year's TurboTax Canadian product activation was keyed on the partition's Volume Serial Number (easily changeable with SysInternal's VolumeID

If you're on Win2K or later, check out Junction from SysInternals. It can create directory-based symlinks on NTFS. Not sure if it's exactly what you're after, but it's pretty useful anyway...

If you're on Win2K or later, check out Junction from SysInternals. It can create directory-based symlinks on NTFS. Not sure if it's exactly what you're after, but it's pretty useful anyway...

This is just not true.

If you are in a networked environment, you might want to use the 'net' command and its various subcommands. Typing the command that launches a service is much quicker than navigating to services in control panel, or in newer revisions of windows (2000 and xp) control panel, then adminitrative tools, just type the command dammit!

Also there are lots of win32 ports of *nix tools that you can use from a command prompt. Check out sysinternals for ports of strings, ps (pslist/pskill), and lots of others.

(not checking link this time because fscking ie doesn't want to remember the form post data like mozilla will and i am typing this for the second time after checking the link on try #1. - yeesh)

http://www.sysinternals.com/ntw2k/freeware/psservi ce.shtml

Wonderful tool. Part of a good package. Free (beer).

What's not to like?

...with strange sets of numbers as names.

Would those start with S1 and contain a lot of dashes? That would be the Computer Security Identifier, and you can (and probably should) alter it to a random string by using NewSID.

If you disable PnP in the bios, it will not allow IRQ sharing which is also a major cause of instability on older motherboards and Win XP.

Soundcard, SB16 emulation on any SB card should be available and if it is not, then chances are the card will not work under Linux if there are no linux drivers since the only other way to get it to work is via SB16 mode..

Legacy support in hardware is an important part of the success of the x86 platform. Advanced features of the hardware may not be available, but the basic functionality will be there.

...unless they use non-MS tools.

Not too familiar with strace, but there is an strace for NT (Alpha build, don't use on production servers according to the notes). Also, Sysinternals makes some good utilities for debugging...which, once again, I don't get into. I'm not sure why having the source code would allow me (a non programmer) to see what the application is doing internally any more than I can deduce what Windows is doing internally by looking at external events. Oh, and tcpdump is also available for Windows as WinDump (bonus points for being BSD licensed).

I've never reinstalled a Windows Server because it couldn't be fixed. I've reinstalled because of hardware failures, misconfigurations or upgrades, but that's about it. I have, however, reinstalled Windows desktops because I didn't want to take the time to fix them. Like I said, though, if I can fix it about 2 hours with a reinstall, it's a better proposition than spending 4 fixing it.

Windows the OS is very stable...it will run on decent hardware for just shy of forever. Windows apps and assorted device drivers, however, are all over the place in terms of stability and are the cause of virtually every BSOD or crash I have ever seen. I do wish Windows had a better model between device drivers and the kernel, but then I don't run flaky drivers on servers...that's more a desktop concern. Flaky apps should be fixed by the vendor or changed to a competing app.

If you feel up to it, go to SysInternals, and download FileMonitor, ProcessExplorer and WinObj. These three tools are hardcore.

Run your app in normal mode, and watch what it's doing with FileMonitor (if you see ACCESS_DENIED entries, you can fix that pretty easily).

Now, if for example, you have a CDROM burner, open WinObj (as an administrator), and go to /device/Cdrom1... check the properties, and select the security tab. You will have an ACL editor a-la file system. There you can allow others than just Administrator burn (write) permissions.

That's a very cool tool. And as you can notice, burn rights are ACL entries, not user token priviledges. BIG difference.

I'm sure there's the same thing for scanners.

All Zealots: please notice how winobj actually shows the real NT namespace. And just like any other system, it starts at /. Also notice /Device/Null, and /Device/PhysicalMemory...

Yes. Just like in NIX.

If you feel up to it, go to SysInternals, and download FileMonitor, ProcessExplorer and WinObj. These three tools are hardcore.

Run your app in normal mode, and watch what it's doing with FileMonitor (if you see ACCESS_DENIED entries, you can fix that pretty easily).

Now, if for example, you have a CDROM burner, open WinObj (as an administrator), and go to /device/Cdrom1... check the properties, and select the security tab. You will have an ACL editor a-la file system. There you can allow others than just Administrator burn (write) permissions.

That's a very cool tool. And as you can notice, burn rights are ACL entries, not user token priviledges. BIG difference.

I'm sure there's the same thing for scanners.

All Zealots: please notice how winobj actually shows the real NT namespace. And just like any other system, it starts at /. Also notice /Device/Null, and /Device/PhysicalMemory...

Yes. Just like in NIX.

If you feel up to it, go to SysInternals, and download FileMonitor, ProcessExplorer and WinObj. These three tools are hardcore.

Run your app in normal mode, and watch what it's doing with FileMonitor (if you see ACCESS_DENIED entries, you can fix that pretty easily).

Now, if for example, you have a CDROM burner, open WinObj (as an administrator), and go to /device/Cdrom1... check the properties, and select the security tab. You will have an ACL editor a-la file system. There you can allow others than just Administrator burn (write) permissions.

That's a very cool tool. And as you can notice, burn rights are ACL entries, not user token priviledges. BIG difference.

I'm sure there's the same thing for scanners.

All Zealots: please notice how winobj actually shows the real NT namespace. And just like any other system, it starts at /. Also notice /Device/Null, and /Device/PhysicalMemory...

Yes. Just like in NIX.

If you feel up to it, go to SysInternals, and download FileMonitor, ProcessExplorer and WinObj. These three tools are hardcore.

Run your app in normal mode, and watch what it's doing with FileMonitor (if you see ACCESS_DENIED entries, you can fix that pretty easily).

Now, if for example, you have a CDROM burner, open WinObj (as an administrator), and go to /device/Cdrom1... check the properties, and select the security tab. You will have an ACL editor a-la file system. There you can allow others than just Administrator burn (write) permissions.

That's a very cool tool. And as you can notice, burn rights are ACL entries, not user token priviledges. BIG difference.

I'm sure there's the same thing for scanners.

All Zealots: please notice how winobj actually shows the real NT namespace. And just like any other system, it starts at /. Also notice /Device/Null, and /Device/PhysicalMemory...

Yes. Just like in NIX.

krmt writes

"Man, if I only had a bunch of virtual desktops so I could have an uncluttered screen."

Virtual Win.

"Wow, what I wouldn't give for grep right now."

Cygwin. Or try this collection of natively compiled GNU utilies.

The registry is a big PITA. Can't help you there. There is a readme describing the structure here, but a lot of programs break that. OTOH, if you don't mind spammy logfiles, regmon can help you find what program is accessing what keys in the registry.

"Stupid spam. I'd love to have procmail running here. Ah well, I guess I'll wait until I reboot to Linux to read my non-web email."

There is a variety of client-side plugins for spam. The next release of Mozilla will also have spam-blocking capabilities.

"It's so great that I've got tabs in Mozilla. Why can't I have them on my windows too like I do in Linux?"

Too bad they don't make a mozilla windows port. Tabbed browsing works great.

I agree, linux is better. But not for most of the reasons you list. :)

It is interesting what you say. I realize I need to know more about this.

Questions: Is it true, then, that to have security we are trusting every Windows program that runs with system-level authority to check for invalid addresses? Since people are migrating from Windows 98, isn't it likely that many programs are not written with this requirement in mind? Is there any list of insecure programs? Everyone seems to agree that it is possible to elevate privileges if McAffee's old virus program is running. What other programs are commonly used that allow users to elevate from guest to administrator?

When someone writes an SUID program in Unix, or uses one, they are particularly aware that there is a problem with privilege. Is it possible that there is no real comparison with Windows programs?

Sysinternal's free utilities PMon v1.0 and Process Explorer v5.25 show a lot of system activity. I know that Windows XP opens a huge number of system-level windows. Is it possible that Microsoft has not checked all of these, so that there are some Windows XP system processes that do not check the process ID or address space? Chis Paget says in his letter to me that is quoted in my article that Microsoft violates its own guidelines. Are you saying this is not true?

There are two issues, it seems to me. What is the usual security that average installations of Windows 2000 or Windows XP owners get, considering that few people understand the vulnernabilities? Second, what is the best possible security that can be achieved by someone who does understand?

Every Windows 2000 or Windows XP program is connected to every other through a single main registry file called SOFTWARE. (The name is in all caps and has no file name extension.) On one machine, for example, this file is 25.69 megabytes; it is a huge file considering that it contains configuration information. It is possible that the vulnerability mentioned by Chris Paget could be combined with a registry access vulnerability? Do all programs that run with administrator-level check their registry entries?

My article, Windows XP Shows the Direction Microsoft is Going, is particularly useful to an executive who has authority over tens or hundreds or thousands of systems. The article warns about technical issues a CEO might not otherwise understand. It is interesting to know about the problems that are likely given normal knowledge of system administrators, rather than just those that cannot be defended against and affect everyone.

I included the privilege escalation issue because Brian Livingston took it seriously, not because I checked it myself. All or almost all other problems in the article are ones I checked myself.

It is interesting what you say. I realize I need to know more about this.

Questions: Is it true, then, that to have security we are trusting every Windows program that runs with system-level authority to check for invalid addresses? Since people are migrating from Windows 98, isn't it likely that many programs are not written with this requirement in mind? Is there any list of insecure programs? Everyone seems to agree that it is possible to elevate privileges if McAffee's old virus program is running. What other programs are commonly used that allow users to elevate from guest to administrator?

When someone writes an SUID program in Unix, or uses one, they are particularly aware that there is a problem with privilege. Is it possible that there is no real comparison with Windows programs?

Sysinternal's free utilities PMon v1.0 and Process Explorer v5.25 show a lot of system activity. I know that Windows XP opens a huge number of system-level windows. Is it possible that Microsoft has not checked all of these, so that there are some Windows XP system processes that do not check the process ID or address space? Chis Paget says in his letter to me that is quoted in my article that Microsoft violates its own guidelines. Are you saying this is not true?

There are two issues, it seems to me. What is the usual security that average installations of Windows 2000 or Windows XP owners get, considering that few people understand the vulnernabilities? Second, what is the best possible security that can be achieved by someone who does understand?

Every Windows 2000 or Windows XP program is connected to every other through a single main registry file called SOFTWARE. (The name is in all caps and has no file name extension.) On one machine, for example, this file is 25.69 megabytes; it is a huge file considering that it contains configuration information. It is possible that the vulnerability mentioned by Chris Paget could be combined with a registry access vulnerability? Do all programs that run with administrator-level check their registry entries?

My article, Windows XP Shows the Direction Microsoft is Going, is particularly useful to an executive who has authority over tens or hundreds or thousands of systems. The article warns about technical issues a CEO might not otherwise understand. It is interesting to know about the problems that are likely given normal knowledge of system administrators, rather than just those that cannot be defended against and affect everyone.

I included the privilege escalation issue because Brian Livingston took it seriously, not because I checked it myself. All or almost all other problems in the article are ones I checked myself.