The Windows and Windows Software Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Windows and Windows Software Megathread

big shtick energy: May 27, 2004

fishmech posted:

Sasser could infect an unpatched XP PC that was behind a NAT router easily.

Uhh, assuming that the router isn't forwarding any ports, as tends to be the default, how exactly is an unsolicited TCP or UDP packet (Sasser was one of those single UDP packet exploits, right?) going to reach the computer?

# ¿ Jun 9, 2009 00:35

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 17:26

big shtick energy: May 27, 2004

imnotzig posted:

Sorry if this has been asked before: Is there a way to disable combining windows on the taskbar, but still hide labels?

If have the taskbar on the side of the screen (instead of the top or bottom) and have combine turned off, it will use the icons but not the text labels.

# ¿ Jun 27, 2009 04:04

big shtick energy: May 27, 2004

I guess people want something to read while installing their two copies of Windows 7?

# ¿ Jul 1, 2009 20:29

big shtick energy: May 27, 2004

Does anyone have the hashes for the x64 pro edition? I don't really trust the MSDNAA downloader.

# ¿ Sep 3, 2009 08:22

big shtick energy: May 27, 2004

Is there an application or anything that will give me "hide labels, don't combine" type behaviour for the taskbar? Or allow me to restore the group with a single or double click or something?

EDIT: Aside from putting the taskbar on the side, since I'd like to try it on the bottom again.

big shtick energy fucked around with this message at 22:37 on Sep 19, 2009

# ¿ Sep 19, 2009 22:34

big shtick energy: May 27, 2004

Xenomorph posted:

You really prefer things without UAC? That means the most destructive malware and most retardedly written applications can happily destroy anything they want in your OS. Windows was actually designed to let this happen before, and only Linux and Mac OS X actually tried to prevent it. Windows has an absolute lovely security record. UAC is a great step to improve security. It puts Windows security back up at a Linux and Mac OS X level.

Yeah except the part where they neutered the security aspects of UAC in Windows 7.

# ¿ Sep 21, 2009 05:22

big shtick energy: May 27, 2004

fishmech posted:

They didn't neuter it, that's just slashdot stupidity.

http://www.pretentiousname.com/misc/win7_uac_whitelist2.html

quote:

Win 7 UAC Code-Injection: How it works

In the quest to reduce the number of UAC prompts, for their code only, Microsoft have granted (at least) three groups of components special privileges:
Processes which anything else can run elevated without a UAC prompt.

This is the list of about 70 processes published on Rafael's Within Windows blog. (Update: New list for RC1 build 7100.) If you run a process on this list and it requires elevation then it -- the whole process -- will be given elevation without showing you a UAC prompt.

Discovery of this list is what lead to the earlier RunDll32.exe exploit where you could ask RunDll32.exe to run your code from within a DLL and it would do so with full elevation and no UAC prompt. Microsoft have since removed RunDll32.exe from the list but there are still plenty of other processes on the list, several of which can be exploited if you can copy files to the Windows folder.

Processes which can create certain elevated COM objects without a UAC prompt.

Programs on this second list are able, without being elevated themselves, to create certain elevated COM objects without triggering a UAC prompt. Once such an object has been created the processes can then tell it to perform actions which require administrator rights, such as copying files to System32 or Program Files.

This appears to be a superset of the first list. In fact, it seems to include all executables which come with Windows 7 and have a Microsoft authenticode certificate.

Unbelievably, as of build 7000 (and confirmed in RC1 build 7100), the list includes not only programs like Explorer.exe which use this feature (or potential security hole, if you like) but also programs such as Calc.exe, Notepad.exe and MSPaint.exe. Microsoft appear to have done nothing to minimize the attack surface and have arbitrarily granted almost all of their executables with this special privilege whether they actually use it or not. You can see evidence of this yourself by opening MSPaint, using the File Open dialog as a mini-file manager, and making changes within Program Files (e.g. create a folder or rename something); it'll let you do that without the UAC prompt that non-MS apps should trigger. I doubt that is intentional and it shows how little thought has gone into the UAC whitelist hacks MS have added to make their own apps seem better.
COM objects which can be created with elevation, by the things in list 2, without a UAC prompt.

Full enumeration of this list has not yet been done. The list is known to include IFileOperation and may simply be all Microsoft-signed COM objects that allow elevation at all.

It does not look like third-party COM objects can be elevated without triggering a UAC prompt, even by Microsoft processes, so the process and object must be on lists 2 and 3 respectively to bypass the UAC prompt. Given the number of processes which can be attacked and the fact that there are Microsoft COM objects to do many admin tasks, that isn't much of a consolation.

My proof-of-concept program is a standalone executable that is run as a normal unelevated process. I made from scratch in about a day and a half. Keep in mind that, while I am an experienced Windows developer, I am not a "security researcher" or "hacker" and this isn't the kind of thing I write every day.

The proof-of-concept works by directly copying (or injecting) part of its own code into the memory of another running processes and then telling that target process to run the code. This is done using standard, non-privileged APIs such as WriteProcessMemory and CreateRemoteThread.

quote:

The underlying problem is that the silent elevation feature, enabled by default in Windows 7 beta, does not check where the code requesting elevation comes from. It checks which process it is running within but not the particular code came from. So, for example, if you inject code into Explorer, or get Explorer to load your DLL, then you can create elevated COM objects without the user's knowledge or consent.

There are many ways to get your code into another process that's running at the same security level. That usually isn't a problem because there's usually nothing you can do in that other process that you can't already do in your own. The silent elevation feature changes that.

Getting your code into another process can be done in various ways. You can use buffer-overflow exploits (although ASLR helps greatly to mitigate those) or you can install yourself as a plugin DLL which the targeted program loads, like an Explorer shell extension. My proof-of-concept program uses a well-known technique called code injection. Code injection has the advantage that you don't have to trick the target program into loading your code; you simply push it into the other process and tell it to run it. This isn't a hack, either; everything is done using documented, supported APIs. (Legitimate uses of the APIs include debugging and inter-process communication. The APIs do not require elevation to use.)

big shtick energy fucked around with this message at 09:19 on Sep 21, 2009

# ¿ Sep 21, 2009 09:16

big shtick energy: May 27, 2004

echinopsis posted:

What about Windows Defender?

MSE replaces windows defender and should be as adequate as anything else to prevent malware infections.

# ¿ Oct 15, 2009 09:51

big shtick energy: May 27, 2004

How come I can't save files to the root of a drive? I claimed ownership of the entire drive for my user account and my account definitely has full permissions for the root of the drive, but it sill doesn't work.

# ¿ Feb 7, 2010 00:18

big shtick energy: May 27, 2004

rolleyes posted:

I just played around with this and got it to work no problems. I opened the drive properties, clicked the security tab, clicked "advanced", clicked "change permissions", clicked "add", and added my personal user account with full control with the "Apply to:" option set to "This folder only." to avoid loving up any other permissions if anything went wrong.

Result was this...

...followed by quite a few "access denied" alerts which I don't quite understand because it should only have been applying the permissions to the folder and nothing else (maybe some sort of inheritance issue? I'm not a Windows ACL genius and root folders are a bit different I think) which was then followed by this (highlighted line is the new entry):

Click here for the full 636x482 image.

Checked I could now save and create files, deleted the permission and everything is back to how it was - i.e. read, list, and exec permissions only.

Weird, I did the same thing and had a "special" entry that was full control and it didn't work. I cleared everything out so that SYSTEM, Users, and my account had full control, but that didn't work either.

EDIT: I even did icacls D:\ /grant Username:(F) and it it didn't change anything.

big shtick energy fucked around with this message at 03:47 on Feb 7, 2010

# ¿ Feb 7, 2010 03:44

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 17:26

big shtick energy: May 27, 2004

Is there an easy way to unpin icons that reference something that doesn't exist? I uninstalled a program and now there's a zombie icon on my taskbar that does nothing when I right or left click on it.

# ¿ Feb 28, 2010 04:47

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Windows and Windows Software Megathread