Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You're kidding, right? You can drop in any executable in place of sticky keys? And it runs with Administrator privileges? How does Microsoft own the enterprise and government spaces with glaring lack of basic security like this? :/


You have to get used to the fact that any physical contact with an unencrypted hard disk, whether it's locked in a computer or not, means that this person now has r/w access to all that data.


The grandparent technique does not rely on physical access to the raw hardware - only mouse, keyboard, and power switch (intended human interface endpoints). The computer case could be behind a concrete bunker with the only communication being cables for the mouse, keyboard, power switch, and video out, and no ports, and this would work.

The Windows security model is intended to protect administrator-account access given these parameters.


.. and so far it has AFAIK never succeeded to protect from all these attacks. That's what I meant with 'locked inside a computer'. It also doesn't matter because in the real world you don't have that bunker in between.


you'd either have it in a bunker with a remote terminal, or you'd get in the bunker after security clearance. making up weird scenario to prove a point is a fool errand, security needs compromise and threat modeling, it's not a blanket meant to protect for every type of attack ever.


I think we should continue to resist accepting this as normal, especially when it's not true for iPhones. We should get used to at-rest encryption. (It seems that part of the current exploit under discussion bypasses Bitlocker?)


Oh, does that get around bitlocker? I didn't get that part. I've assumed bitlocker uses a keyfile encrypted with the user PW?


As a kid I did this with magnify.exe to get around account time restrictions (hi, Dad). Enabling magnifier from the accessibility dialog on the login screen would pop open a command prompt running under the SYSTEM account. Punching in "explorer.exe" would get you a desktop.


Smart parents lock down their kid's computer to turn them into better hackers


I can't remember where I saw it, but here's how you teach your kids to start scripting:

Step 1: put a note on the fridge saying "The new WiFi password is one of the 10 random keys in the text file on this USB drive [taped to note]".

Step 2: wait a few days, repeat Step 1 with 10 replaced by 10 000 and also leave them an intro to Python (or $favorite_lang) book. Bonus points if you make the USB drive boot Linux straight to a Python REPL.


I had to learn lock-picking first to have access to the mighty computer room, first. After a while I discovered that I could kick the door open easily. Then they realized the door was wobbly and replaced the entire frame. That's how I learned brute-forcing was not a viable long-term strategy.


Yes, I was doing it for years since Win98. There even was Linux distro dedicated for it called logmein that has something like 35MB. I still have .img of it, if you would like to test it. The distro was no longer supported since Vista, but still worked on win7.


Yup. You can also drop in any executable in place of the "accessibility center" which, of course, also runs as admin in the login/lock screens.


You can also drop (almost) any executable in place of explorer.exe, it's the basis of Windows Server "Core".

It has both good and bad sides, and the same (basic) thing is exploitable on linux. You can replace `cat` with another executable and change the PATH so that the new `cat` comes first.

   /tmp/cat
   PATH=/tmp:$PATH
edit: I'm aware that this does not give root privilege (though it could, through some SUID hack or cowroot or anything really), but it is the same basic "flaw". (again, though it isn't really a flaw)


I think the Linux equivalent would be more like interrupting the boot process at the GRUB menu, then adding "init=/bin/sh" onto the kernel command line, so Linux boots into a root shell.


Yes, how does this run your executable with root privileges as with the Windows example?


Not really. In any Linux system I've seen,if you can change PATH you can already execute your /tmp/cat directly. And generally PATH and LD_LIBRARY_PATH are not passed through suid or sudo.


And this, folks, is why you shouldn't have "." in your PATH.


Yeah, not really, that's what I'm saying in all my parentheses...


Explain how this is a security threat like the Windows example given here?!




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: