New Windows driver signature bypass allows kernel rootkit installs

That used to be the issue in the XP era, and is the reason why the transition is why UAC was so hated. But today you can have a very normal desktop experience without admin permissions.

You have to switch to your admin account for some settings and maybe half the time you are installing new software, but everyday stuff now works well without privileges

Best way to protect windows at home is actually to have two accounts - one standard you login with and use day to day and another admin account you really never need to login as. Anytime you need to install something or get admin access a pop up asks for your admin account and password.

Basically this is the default way Linux works (not entirely the same but similar enough) with sudo. And the way that every corporate IT department runs windows.

Another advantage is that if some malicious app tries to access something it shouldn't you will immediately know as the admin pop up will trigger.

I've been using a separate, local admin account and non-admin users for a while for friends and family.

There's not a lot a typical user does that requires admin. For the odd software that breaks Windows' conventions, it's usually enough to install it outside of Program Files.

Of course with the push towards Microsoft accounts for login, this might soon be difficult.

I run my personal desktop as a non-admin user. Every now and then I need to provide creds to my admin account, but the majority of what I do does not require it.

Depends what you're doing?

> Which makes no sense.

You're twisting what "makes sense" means here. What they're saying makes sense with respect to the current design. They have had a design with one sharp security boundary and maintained it... for decades. Their statement is entirely consistent with that, and in no way nonsensical. You're saying it "doesn't make sense" to mean "I think this is poor design, and there should be multiple layers of security boundaries", and you're obviously welcome to have that opinion, but that doesn't mean their disagreement implies their statement is nonsense.

I fail to see the fundamental difference with Linux you're talking about. Typically adding a user to the sudo/wheel group mean precisely that they can run whatever as the superuser (root). Once you're root, Bob's your uncle.

Sure you can tweak it to only allow certain commands, restrict it to another group, etc. Which would be equivalant to, in Windows, probably using another group(s) than Administrators and assign privilegas as appopriate.

I have a lot of unfavorable opinions of security fundamentals in Windows but you're barking up the wrong tree here.

From your other comment in this thread:

> The issue is not that people don't understand how MS defines what is and is not a security boundary.

With all due respect, check your assumptions...

I think your example is accurate.

I think there's another example around trans-vocabulary:

The analog of the 1st half is "I'm not going to stop you from cutting off your man bits, but don't expect me to call you a 'woman'. 'Trans woman' is ok because that's a new word, but 'woman' already has a meaning and don't try to change it."

The analog of the 2nd half is "You shouldn't do that because you're a man and you need to act like one." Or perhaps it's an affront to nature or the divine.

> Some would say "gay people should be able to do what they want and form 'civil unions' with all the tax and contractual benefits and requirements of marriage, but they shouldn't be able to get 'married'".

> Other people opposed gay marriage because it went against their values.

This difference does not matter - the outcome was the same. Stop treating bigots with kid gloves.

I see what you're saying...

I think the sibling comment accidentally put it better.

> There are also people who disguise their value disagreement as a definition disagreement.

Or maybe even more to the point: they are twisting their definitions to support their values.

I think we can agree on this.

> this is not a value system disagreement.

Yes, it is. The issue is not that people don't understand how MS defines what is and is not a security boundary. The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.

I think that's helpful for me and my theory. Informed by Socrates I will refine my theory. O:-)

There's three forms of disagreements.

1. Disagreements on definitions

2. Disagreements on facts

Kind of hard to disagree on logical implications

3. Disagreements on value systems

Not to be dense, which is most difficult?

> We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.

> Those OS go out of the way preventing features that hinder usefulness of the devices.

But one isn't necessarily synonymous with the other.

Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it.

Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for.

The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode.

This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.

Recording phone calls is possible in principle. The reason that it is not available on some devices or in some regions is that there are legal requirements which manufacturers have to adhere to in order to get their devices certified, i.e. in some countries it is illegal to record phone calls, in others explicit permission needs to be given, reason for manufacturers to take the safe route w.r.t. liability and disable it in those countries too, or even globally.

There's a middle ground where apps are sandboxed but you're still in full control... But of course OS vendors will not allow that, so we're just daydreaming here.

In the case of Windows, a lot is about compatibility. You can design a different system, but then a lot of existing software that users care about won’t properly function on it anymore.

However, if you read the article, the vulnerability is enabled by a race condition in a Windows security component, so really just a bug here, even if Microsoft is trying to deflect from that.

1) drivers should be apps too (Redox and others (even macOS partially) get this right)

2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear

>> Its the most widely deployed desktop os across rich targets

>There are more computers running Linux

You did not address the claim you replied to. Users get compromised, and users use windows desktop.

The number of DB clusters or whatever running *nix isn't relevant.

Most of them are offering nothing more than an ssh or web service. Not really a great or fair comparison.

Linux on the desktop is the least secure option out of Windows and macOS, barring RHEL with it's SELinux policies which probably put it ahead of Windows and macOS as well.

> There are more computers running Linux on this earth by orders of magnitude.

Yes, but most of them aren't running GNU and have signed boot with no ability to disable it. Very shallow victory. Could turn into FreeBSD tomorrow, and very little ground would be lost.

And almost none of those bother doing things like checking driver signatures at all. You don't need to figure out hacks like "downgrading the OS to bypass signature validation logic" when you can `insmod` the moment you get admin/root permissions.

You could configure all manner of security settings on Linux, of course, but on most Linux distros they're all left unconfigured.

For a while apple had better security. Now it's more even, if you go by the 0day prices. There's not a lot of truly secure options unless you wanted to develop your own phone from the ground up.

Wait until all those regulations requiring apple to allow different app stores come online and then we will see how secure iOS is. The day Joe Clicks-A-Lot can follow a link in some random pig butchering scam email then “legally” sideload and run whatever crazy weird goop happens to be at other end will really put things to the test.

Because letting Susie Easy-To-Phish install anything and everything on her iPhone is going to make things very… interesting.

That being said, Joe and Susie can already do that on android right?

> But wasn't that Windows rebuilt from the ground up as Windows NT

That was the 1990s. Windows security was transformed in the 2000s and then with Windows 10. I'm not sure it can be said to be more vulnerable than other OSes.

Of course. A new secure computing platform would have to be built from scratch and from secure primitives that would not be backwards compatible with anything outside of virtualized emulation.

When that worm was created Windows did not exist.

UNIX entire security model is "ambient security" in operating systems literature.

Ambient security is a joke. Real security requires a capability-based model.

seL4[0] implements the mechanisms to do this efficiently. Lions OS implements an entire system with seL4 as core[1] leveraging these mechanisms.

0. https://sel4.systems/About/seL4-whitepaper.pdf

1. https://trustworthy.systems/projects/LionsOS/

But is the virtualization component fully verified?

IANAL, but this seems more like a classic temper tantrum thrown by a big corp over reasonable legislation.

They could offer an API for security relevant scanning for EVERYONE, including their own antivirus software. But that would make the world better, and make the legislation look justified.

It's the exact same thing with the Google Maps integration on Google Search. They could offer an API and a selection of map provider to the user. That would make Google Search better for the user AND enable competition. Instead they threw a temper tantrum and disabled map integration entirely, so they can blame the EU.

There’s two parts to it.

Microsoft claims they need kernel level access to implement their paid for security product ( Windows defender while free for home use is not free for enterprise )

If they firmly believe that, then they cannot block other software from having the same access or it would be anti trust.

They could perhaps make it free and bundled in windows, but they don’t want to lose the enterprise funding.

What might be enough is to have windows required to boot in a “install” mode before 3rd party kernel code can be added.

If you want to include anyone with an android device as a linux user then most of them are not.

There are multiple ways to set things up in Linux. You can use sudo, or you can have a separate root user.

I have not used Windows enough in recent years to know, but there may be differences in what you need to enter your admin password for, which may make users less suspicious when asked. On Linux distros I have used the only regular operation on a desktop that requires it are software installation and updates updates, which has a well defined UI and comes after a specific user action.

I'm happy to complain about Windows, but I will say their progress in converting their ecosystem to user-by-default with elevation prompt warnings has been impressive.

Especially when they had to drag their developer community kicking and screaming to it. (in Windows Vista ~2006)

Afaicr, there's also a neat bit where the lock screen and UAC prompt actually run under an entirely different, privileged and restricted session (than the normal one the user is interacting with and running programs in).

Ref: https://learn.microsoft.com/en-us/windows/security/applicati...

Apparently now termed the "secure desktop", it's transparently overlaid on top of the user desktop whenever you see a prompt.

What action requires admin escalation on Windows but not on Linux?

Well, the main difference is that one you just click "yes" and the other you usually need to enter a password.

Then there is also polkit, which does something similar to sudo, but for a different usecase (authenticating unpriviledged process access to a priviledge process). Polkit to my knowledge can differentiate between actions to "always allow", "requires confirmation" (press yes) and "require password".

Linux also has SELinux, root can't do everything there.

Yep, when booting with secure boot the kernel won't load any unsigned drivers.

>Browsers only just recently patched browsers being able to be served javascript that scans local devices on 10.* and 192.168.* etc hitting IoT devices with exploits and payloads, hell even hitting open listening sockets on localhost and 0.0.0.0 -- that's cross platform, how many years did that go under the radar?

Ironically windows was not hit by that, but the "secure"(?) operating systems of mac and linux were.

What? I never said being computer illiterate is bad. Plenty of fine people are computer illiterate. And plenty of fine people are fantastic at things I'll never be good at. That's fine.

Which is the wrong path IMO. If users want to shoot themselves in the foot, let them do it. The only way to learn responsibility is to let get their systems pawnd. Maybe they will finally learn the Linux way - never login as admin, always as normal user. You want admin login? Cool, then the "su" equivalent in Windows is called "runas".

On the Windows side, loading arbitrary kernel code is an annoying process that involves disabling driver validation+dev mode and one or two reboots. If all components are working well, merely being an admin does not grant you arbitrary kernel access like it does on most Linux configs. You need to pay for/steal someone else's code signing certificate or reconfigure the target to boot into a special mode (that may require a Bitlocker recovery key). Nothing a malware author can't do, but like on the macOS "verify every binary" approach, a malicious actor can be blocked with a single certificate revocation at that point, no AV necessary.

As for groups, Windows has a variety of groups with a range of permissions (both local and over network shares). On home installs, the default user will have all of the permissions, kind of like on how most Linux installs have a single sudo/wheel user. Every kernel object has a different ACL that can be altered down to the user level. Furthermore, Windows differentiates between various permission levels ("browser content rendering process" vs "normal process" vs "admin process"), doing things like preventing keystroke insertion into higher privileged processes running under the same user account.

In office/corporate environments, the person interacting with the computer never gets admin permissions at all, so the admin/kernel boundary isn't relevant until a privilege escalation exploit is involved. Even IT administrators should almost never use real admin accounts; almost everything from changing passwords to reconfiguring permissions and settings can be done with assigning users to lower privilege groups or the right ACLs, not entirely unlike how Linux capabilities can be used to grant relatively low-power users permissions that normally only root can use.

Windows's security problem isn't unlike Linux's: it can be locked down securely, but you'll break tons of applications and you'll need to read through tons of obscure documentation before you can pull it off. Out-of-the-box Windows has a lot of security features that Linux lacks, but when it comes to unmanaged home computers owned and used by normal people, neither has any real protection boundary preventing kernel access in practice.

Because their policy is to not give admin to a user if you don't want them to have control of the computer?

It's not as good as SELinux but you can limit the rights of admins with group policy so that they won't be able to install random drivers in the environments you speak of that need that boundary.

It's the decision to use hex at all which is weird. I don't think most of this crowd would be particularity impressed by it.

As a user who does have need for kernel access, because it's my god damn system and not yours, Microsoft's or anybody else's, I don't want it locked down.

It's called security in depth. That means you don't need to prevent all kernel access for users, because there are layers of defense.

But you know what's even better? Having a choice.

Want to lock down Windows? You should have that power. It would be absolutely idiotic if you couldn't secure a computer. But, do you want to fuck with the kernel, patch out something you think should never be called by anything because there is no legitimate use case? You should also have that power.

Because one thing that stuff like this doesn't do is "make it easier for the bad guys": want to deliver a malicious payload by exploiting Windows, either because of its design or a recently found vector? I hope you die in a fire but you already have so many options that this one really doesn't give you more power than before. It's just another option in a litany of options. After all, Windows is only as safe as its users with admin powers, which is literally every home user thanks to elevated access being a single "ok" button, if they even have UAC still turned on "because it's so annoying".