Unfixable Windows flaw

Hmm... I like this discussion! :bigsmile:

Quote:

---

Originally posted here by problemchild


Just because someone can get to the console it's normal for them to be able to gain Administrator access? I beg to differ. What's the point of having different users and ACLs at the console if that's true?

---

That's a good point, problemchild, but if I can reboot the machine, what's to stop me from modifying the password files for the Administrator account using an NTAdmin recovery disk? Those controls are helpful, but they're hardly foolproof. I've always thought that one of Windows' biggest flaws was that they tried to take an environment that was built to be an individual desktop environment and make it a multi-user environment. If you think about it, the Windows "single user mode" would probably be most closely related the 'Recovery Disk' that you're supposed to create on installation.

Quote:

---

Originally posted here by problemchild

As for Linux, I disagree. You set your BIOS boot sequence to exclude floppy and CD-ROM so that it only boots from the hard drive and put a setup password on the BIOS so nobody can change it. Then you set your lilo delay to zero and password protect single-user mode. Thay way, nobody can boot some other meduim or OS and reset your passwords. The only way around it would be to take the cover off and reset the CMOS jumper, which if you have even a modicum of physical security should be pretty consipcuous.

---

Just as I mentioned above, if you have physical access to the machine, you can reboot it and compromise any console security for just about every OS. You mentioned that hopefully everyone would have a modicum of physical security to prevent tampering to the CMOS jumpers. I agree wholeheartedly, and that's exactly my point. You need to have a great deal of physical security to protect the console. It is one of the greatest vulnerabilities in your system. It's sort of like lockpicking. All pin-tumbler locks are made to have just a little bit of play in them so that a professional locksmith will have the ability to open the lock without a key. If you don't have some way of bypassing system security, you could potentially lose a great deal of data should you ever forget or lose the password. Especially for those systems that encrypt stored data. Without some kind of physical security (proportional to the value of the system and the potential threats) surrounding the console, you might as well be giving out guest accounts!

The college campus scenario is where this can be used and abused. It could also be used in call center type operations where they severely restrict what the phone operators can do.

Here is the scenario. You have 100 windows2k machines that all have a bios password, and have set only the harddrive as a bootable device. You have case locks and physical security(security guards, cameras, etc..) that will prevent someone from opening the case and doing any type of alternate boot scenario.

Now.. You have a global group called students, and a global group called admins. Obviously you are only going to put students into the students group. To lock down security even more you implement GPOs that prevent the use of "RUN", downloading files from the internet, and only disable all software except for IE and "Office" applications.

OK.. So you say that the desktops are secure. The students can only use productivity type software, so they cannot use IRC or WinMX, etc... This is not the case anymore given this flaw..

I have to disagree with what the article says about it being unfixable. I'm pretty sure there is a managed object that you can restrict access to and thereby defeat this vulnerability. However, as no in depth technical details have been given about how exactly it was done, I can't give you that info.

Quote:

---

what's to stop me from modifying the password files for the Administrator account using an NTAdmin recovery disk?

---

That was my point.... if the BIOS is set to only boot from the hard drive and has a setup password to prevent you from changing it, and the boot loader is set to zero delay, and the drive has an encrypted filesystem, and the case has a lock on it to prevent you from taking the cover off, how are you going to boot your recovery disk? I used to admin a couple of student labs in college, and this is exactly what I did with them.

Heck, if you were really paranoid you could yank the floppy and CD-ROM drives out completely once the box was configured. I promise you I can stop you from booting your recovery disk if I want to badly enough.

Quote:

---

I've always thought that one of Windows' biggest flaws was that they tried to take an environment that was built to be an individual desktop environment and make it a multi-user environment.

---

I agree completely. See my post on this very topic here.

Quote:

---

if you have physical access to the machine, you can reboot it and compromise any console security for just about every OS

---

And as I said, not if you configure everything properly. There are lots of ways to prevent this.

Quote:

---

I agree wholeheartedly, and that's exactly my point. You need to have a great deal of physical security to protect the console. It is one of the greatest vulnerabilities in your system.

---

There's a big difference between noticing some kid cutting the lock off the cover with a pair of bolt cutters, and somebody standing there watching every keystroke every user makes to be sure they don't run this shatter exploit from a floppy disk instead of that Comp 101 paper that's due in the morning. There's no comaprison, IMO.

Quote:

---

you might as well be giving out guest accounts!

---

I'd settle for guest accounts right now. As it stands, we're giving out administrator accounts.

Excellent point, mohaughn. It definitely depends on the role of the system when judging the severity of this bug. When I replied, I was considering the target system to be an Exchange server, print server, or some other production-level, mission-critical role. Like many UNIX systems, these systems rarely see a console operator when they're running smoothly. The security around these consoles needs to be air-tight. The student lab/library however is a completely different scenario where security is compromised by the need for accessibility. However, while this bug could easily be exploited on these public systems, sensitive data should never be stored on them. If such data needs to be accessed, it should be remotely accessed from a central server and distributed accordingly. Systems whose keyboards are touched by several hands should be carefully watched and seldom trusted.

problemchild -- I think we agree, just not on the terminology. :bigsmile: When I say "Security is already compromised if you have access to the console", by console, I'm talking about unhindered access to the physical system. By removing the floppy drives, adding padlocks, adding security guards/cameras, using infared beams and sophisticated biometrics, you're adding physical security that prevents my unhindered access to the physical system. I consider the BIOS passwords and boot order part of the software of a system. If you were just to employ those software controls without some kind of physical deterrent in combination, those software controls are useless. So I agree with you that there are ways to keep someone from monkeying with a console, but not without some kind of hardware deterrent.

Quote:

---

However, while this bug could easily be exploited on these public systems, sensitive data should never be stored on them.

---

It's not a question of what people are going to get off of the system. It's a question of what people are going to put on these systems. Like warez and MP3s...... see my post above.

Good point! Every security threat is different, and I hadn't considered the threat of public systems being used as servers. You're right, this Windows bug blows goats!

However, just to play devil's advocate, you may be able to deal with the threat of public terminals becoming servers (although how effectively I don't know) by establishing some kind of weekly (if not nightly) image restore policy. I know a couple of labs that do an image push every night, and every morning is a new lab of freshly installed Windows machines. This may work on labs that aren't open 24 hours. For those, you'd have to incorporate some kind of usage rotation while some of the terminals are being restored. Kind of a jooky way of doing things, but it might work for someone.

As has been replyed in bugtrack's mailing lists, this has actually been known for quite a while. By itself, this "mechanism" is not a bug. The problem comes from SERVICES RUNNING GUI FRONT ENDS AS LOCALSYSTEM. This is obviously bad design from the application vendors. Such application designs would be immidiately flagged as flawed if they were for linux/unix. Good design practices would have the GUI frontend running with the user permissions connect to the back end (through named pipes or wathever) running as deamon/root. The ironi in this is that many personnal firewalls, supposed to make the computer secure, are in such situations.


Ammo