[HN Gopher] New Windows driver signature bypass allows kernel ro...
___________________________________________________________________
New Windows driver signature bypass allows kernel rootkit installs
Author : sandwichsphinx
Score : 241 points
Date : 2024-10-26 14:12 UTC (8 hours ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| tomrod wrote:
| I'm not by any means a security guru. I understand some basics,
| but I think I'm missing a conceptual model somewhere. What is it
| about Windows that makes it so damn hackable?
| high_priest wrote:
| From my experience, it's that users are administrators by
| default. And it is super easy to convince them, to run anything
| with elevated permissions.
| SoftTalker wrote:
| As if most linux users aren't also in the sudo group?
| graemep wrote:
| 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.
| gruez wrote:
| >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.
|
| clearly you haven't seen all the projects on github where
| the instructions are "curl ... | sudo sh". Moreover, the
| security model behind sudo is so hilariously bad that
| it's trivial to get EoP[1]. UAC might have plenty of
| exploits (usually around auto-escalation), but at least
| they make an attempt at making it secure.
|
| [1] tl;dr: modify $PATH to contain a bobbytrapped version
| of sudo that executes the command you want, plus whatever
| evil stuff you want.
| mycall wrote:
| Reserve shells are indeed simple in *nix
| tempest_ wrote:
| If you want to include anyone with an android device as a
| linux user then most of them are not.
| advael wrote:
| At this point few besides the pedantic or motivated seem
| to want this, given that they've been massively diverged
| projects for at least half a decade
| card_zero wrote:
| Is that different from sudo?
| NekkoDroid wrote:
| 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".
| admax88qqq wrote:
| The main difference is that UAC is automatically
| triggered by the OS and takes over the whole display
| making it harder to fake/intercept. It's trivial to put a
| fake sudo in someones PATH and steal their password
| survivedurcode wrote:
| lol UAC is such a lazy shitshow of a security
| implementation...
|
| A) there is no interception to be had. It's a fucking
| "Yes I am Admin" single click a child could do
| unsupervised.
|
| B) It requires training for the user to know that this is
| a special UAC mode. That's high-motivation, high-
| knowledge user training. Pilots train to recognize
| unusual signs. Your grandma does not train to recognize
| what UAC looks like, why it would come up and when. UAC
| is the biggest cop out of a security excuse and Windows
| should be ashamed.
| admax88qqq wrote:
| Sure I guess, I don't know why UAC gets so much hate
| while sudo gets so much praise.
|
| UAC is strictly better than sudo IMO.
|
| Does UAC solve security for windows? Of course not, but
| we were comparing against sudo here.
| rockskon wrote:
| The alternative to that is Android and IOS where we don't
| have full control over our own devices unless we jailbreak
| them, which itself breaks so many critical apps on the mobile
| device stores that it's frequently not worth it to root the
| device.
|
| No - the problem here is moreso the sheer complexity of
| Windows and the variety of devs involved and the push for
| backwards compatibility.
| ajross wrote:
| The exploit under discussion is an attack on Windows Update,
| it doesn't AFAICT involved running privileged code as the
| user. Also the default Windows user has been non-
| Administrator for many years now. It's true you can fool
| users into elevating a shell or whatever, but that's true for
| pretty much all platforms.
| ethbr1 wrote:
| 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.
| dimensi0nal wrote:
| It's not a transparent overlay, it's a completely
| separate desktop with a screenshot of the user desktop as
| its background. Really clever.
| wongogue wrote:
| And 50% of the times, the background fails to load and I
| have to double check. At first I thought it may be my
| specfic hardware combo but no.
| magicalhippo wrote:
| And that the desktops are securable objects[1], so
| processes in the default desktop can't snoop on what's
| going on in the winlogon desktop say when the UAC prompt
| is shown.
|
| [1]: https://learn.microsoft.com/en-
| us/windows/win32/winstation/d...
| advael wrote:
| It'd be a lot less easy if the OS didn't seem to require full
| privilege escalation for a lot of tasks you don't need that
| for in linux. One of the major problems that leads to
| escalation is poor separation of concerns
| tredre3 wrote:
| What action requires admin escalation on Windows but not on
| Linux?
| advael wrote:
| Just counting things I've personally seen, using
| "untrusted" userspace software and accessing a USB
| webcam. It's possible these particular examples are no
| longer true. I haven't been a windows user for about 15
| years. But both surprised me quite a lot when I saw
| people I know do them and it seemed indicative of a
| systemic separation of concerns problem
| joshuaissac wrote:
| > using "untrusted" userspace software and accessing a
| USB webcam
|
| Windows only requires escalation for this if you want to
| install that userspace software to a non-user location,*
| or if you want to install a driver for the webcam.
|
| If you just want to run the program, this is not
| required.
|
| A long time ago, in the pre-Vista era, when running
| programs as administrator was the default, many programs
| would not work if they were not run as administrator.
| This is no longer case for programs written after Vista.
| From Vista onwards, older programs that assume admin
| rights and attempt to change admin-only files get their
| reads and writes redirected to a VirtualStore folder
| within the user's profile, so that the program still
| works without administrative permissions.
|
| * The exception is with some installers where the UAC
| installer detection kicks in and demands escalation
| straight away, even before you select an installation
| location (which could be a user-writable location).
| Turning this off requires using the Group Policy Editor
| or the Registry Editor to flip the
| EnableInstallerDetection registry key.
| pcdoodle wrote:
| IMO: The backward compatibility and lots of hands touching many
| moving parts.
| jsheard wrote:
| Yep, the almost impenetrable security of the last few Xboxes
| shows that Microsoft does have it in them to architect a very
| secure platform, even against physical attacks, but they
| don't have the luxury of doing such a clean-slate design with
| Windows. They can almost never afford to break backwards
| compatibility and the Xbox approach of running each instance
| of legacy software in its own fully isolated virtual machine
| wouldn't really scale to a multitasking environment.
|
| For those not keeping score, the Xbox One only recently got a
| very limited jailbreak a decade after release, that only
| works on old firmware and only allows access to the innermost
| level of sandboxing, with the outer system sandbox,
| hypervisor, bootloader and optical drive handshake remaining
| unbroken to this day.
| throwaway48476 wrote:
| The Xbox is 'secure', but against the user. There are a
| great many PC's out there that this model doesn't work for.
| lock_it_down wrote:
| It's secure against everyone, including the user.
|
| Windows could relax that part a bit if they wanted.
| Citizen_Lame wrote:
| It's not an error, it's by design. Only issue is these
| "vulnerabilities" were reserved for three letter agencies.
| mardifoufs wrote:
| What do you mean by hackable? I can't really see how other
| operating systems (say, Linux+any distro) are more secure than
| windows fundamentally?
| peppermint_gum wrote:
| What makes you think that it's "so damn hackable"?
|
| Also, this particular attack requires administrator privileges
| and bypasses a security boundary that doesn't even exist on
| e.g. Linux. Linux doesn't have driver signatures and root can
| easily install a new kernel module.
| mrinfinitiesx wrote:
| Just a quick look at 2024's CVEs, 0days for Windows is a
| security nightmare. Not singling out Windows specifically,
| but they have a lot.
|
| 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?
|
| And now Windows is getting 'Recall' which will monitor and
| scan your every PC action to remember it for you using ML; I
| don't see that going back at all /s
| gruez wrote:
| >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.
| formerly_proven wrote:
| > Linux doesn't have driver signatures and root can easily
| install a new kernel module.
|
| Linux supports signed kernel modules (and not just on paper,
| this is a widely deployed feature).
| NekkoDroid wrote:
| Yep, when booting with secure boot the kernel won't load
| any unsigned drivers.
| snvzz wrote:
| This claim still assumes there's no vulnerabilities in a
| TCB sized in the millions of LoCs.
|
| No chance.
|
| Look elsewhere for actual security.
|
| Right now, elsewhere just happens to be seL4. Anything
| else is either still too green or an architectural non-
| starter.
| ddtaylor wrote:
| Linux also has SELinux, root can't do everything there.
| beeboobaa3 wrote:
| It allows it's users to actually use their computer as a
| computer instead of a glorified phone.
|
| MacOS nannies you left and right, preventing you from doing
| things you want to do because Apple says no.
|
| Windows historically didn't have such restrictions because it's
| a desktop operating system and not a gimped phone. They're
| slowly being added, but it takes time to overhaul an entire
| architecture while maintaining backwards compatibility (which
| MacOS also doesn't care about at all).
|
| Linux is of course far more "hackable" but there aren't as many
| computer illiterates using it.
| bubblesnort wrote:
| I let the illiterates use it, but if they don't need root
| they don't get root. Debian stable with auto-unattend.
| survivedurcode wrote:
| LOL you should be upvoted as your comment perfectly captures
| the blind arrogance of the software industry.
|
| When you call people computer illiterate, you are blind to
| the technocrat injustice imparted onto the general populace.
|
| > The obnoxious behavior and obscure interaction that
| software-based products exhibit is institutionalizing what I
| call "software apartheid":"
|
| > -- Alan Cooper, The Inmates Are Running the Asylum: Why
| High Tech Products Drive Us Crazy and How to Restore the
| Sanity
|
| > "When programmers speak of "computer literacy," they are
| drawing red lines around ethnic groups, too, yet few have
| pointed this out."
|
| > -- Alan Cooper, The Inmates Are Running the Asylum: Why
| High Tech Products Drive Us Crazy and How to Restore the
| Sanity
|
| You too can see the light and rise above the elitism of
| computer literacy. You know, there are many smart people that
| are too prideful to put up with what computer people demand
| as computer literacy. They suffer in silence, you will not
| have their loyalty, and they will switch to competing
| software the moment they are able to.
| beeboobaa3 wrote:
| 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.
| nwellinghoff wrote:
| Can't believe people have not pointed out the biggest reason of
| them all. Its the most widely deployed desktop os across rich
| targets (corporations). A lot of time and investment goes into
| cracking it.
| ddtaylor wrote:
| There are more computers running Linux on this earth by
| orders of magnitude.
| gjsman-1000 wrote:
| > 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.
| anthk wrote:
| You forgot servers.
| kryogen1c wrote:
| >> 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.
| jeroenhd wrote:
| 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.
| n_plus_1_acc wrote:
| Tens of millions LOC in legacy C++ with many many compatability
| layers.
| robhlt wrote:
| The prevalence of 3rd party kernel-level code is an important
| factor too. Lots of windows malware relies on a vulnerable 3rd
| party kernel driver at some point.
|
| By comparison, 3rd party kernel modules are rare and looked
| down upon on Linux and outright banned on macOS.
| makeitdouble wrote:
| To note, Windows isn't allowed to completely block third
| party kernel code.
|
| I don't have the reference at hand but it was part of their
| various anti-trust fallout, as it would give them an unfair
| advantage regarding to their own products.
|
| PS: an analysis of that situation during the Crowdstrike
| issue, with the relevant bits of the EU ruling:
| https://www.computerweekly.com/news/366598838/Why-is-
| CrowdSt...
| spockz wrote:
| What might be enough is to have windows required to boot in
| a "install" mode before 3rd party kernel code can be added.
| LinXitoW wrote:
| 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.
| dwattttt wrote:
| > They could offer an API for security relevant scanning
| for EVERYONE, including their own antivirus software
|
| I mean, they have _lots_ of APIs. You'll just never have
| as much control from usermode as you will from the
| kernel; what API would make you say "yep, don't need a
| driver now, can do security fine from user"?
| dagmx wrote:
| 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.
| camus_absurd wrote:
| Not banned, you just have to go through some hoops to enable
| installation of third party kernel extensions
| throwaway48476 wrote:
| The problem is that windows was developed before security was
| important. No one has made the necessary investments to create
| a truly secure computing platform.
|
| Ideally a secure computing platform would have reproducible
| builds built on public inspectable infrastructure like fdroid.
| It would also virtualize all untrusted applications in a
| sandbox and implement the least privilege model.
|
| Today we have the worst security. There is unknown, probably
| untested and insecure code running at every ring, from the
| CPU's ME, to the UEFI components, to the OS 3rd party drivers.
|
| SeL4 has a fully verified kernel but it doesn't do
| virtualization yet.
| pjmlp wrote:
| The same can be told of UNIX, lets not forget the first worm
| was targeted at UNIX systems, and the root cause keeps being
| a regular CVE in C and C++ projects.
| throwaway48476 wrote:
| 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.
| ddtaylor wrote:
| When that worm was created Windows did not exist.
| pjmlp wrote:
| And yet the root cause for it still hasn't been fixed in
| UNIX systems.
| anthk wrote:
| If you consider plan9/9front Unix 2.0, they did with
| namespaces.
| pjmlp wrote:
| Namespaces have nothing to do with buffer overflows.
| morpheuskafka wrote:
| > The problem is that windows was developed before security
| was important.
|
| But wasn't that Windows rebuilt from the ground up as Windows
| NT, which had more advanced security features out of the box
| than basic Unix/Linux (allow/deny ACLs vs octal permissions,
| SAM database vs /etc/passwd flatfile, SIDs vs manually
| assigned/reusable UIDs)?
|
| (And some other cool design features that never got used,
| like POSIX/OS2 subsystems being on equal footing as the
| "regular" Windows32 subsystem.)
| mmooss wrote:
| > 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.
| dagmx wrote:
| It's definitely more vulnerable than macOS since macOS
| has more encompassing system protection (SIP), kernel
| extensions have been moved to user space (DriverKit and
| FSKit), and pervasive sandboxing.
| gjsman-1000 wrote:
| > Ideally a secure computing platform would have reproducible
| builds built on public inspectable infrastructure like
| fdroid. It would also virtualize all untrusted applications
| in a sandbox and implement the least privilege model.
|
| Also, be careful what you ask for. Such a system would likely
| require Secure Boot to be enabled _a-la_ Android, complete
| with userspace detection of a system which does not have
| Secure Boot enabled, for DRM implementations similar to a
| game console. We 're already close, but UEFI bugs,
| virtualization, hundreds of TPM variants, and bus attacks
| have left holes.
| robocat wrote:
| > windows was developed before security was important
|
| I disagree - At best you could say DOS was developed before
| users knew security was important... Microsoft has explicitly
| ignored security since DOS - because functionality sells
| better than security. Anyone who has worked with Unix systems
| has always understood just how much of a sieve Microsoft OSes
| are. Anyone with wisdom has said that about Windows from the
| very very beginning. Windows anti-virus has been a thing for
| a very long time.
|
| If your prior is the number of extreme security
| vulnerabilities in one year - the implication is that there
| are lot of undiscovered extreme security vulnerabilities.
|
| And competent WaaS (Weaponisation as a Service) now exists to
| quickly deploy exploits for obscure weaknesses or recently
| discovered weaknesses. Users and companies no longer have a
| few weeks grace before mass exploitation occurs.
|
| Use Windows, get pwned. The counterfactual is difficult: it
| is hard to prove you haven't been pwned... Anti-virus defence
| is often too late (plenty of examples eh!).
|
| I've seen very careful users/developers get caught out again
| and again.
|
| Not to say Windows is alone. Routers and other end devices
| are just as bad. And Android doesn't appear great to me
| either.
| snvzz wrote:
| 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/
| anthk wrote:
| Check 9front and GNU/Hurd. Namespaces are good too.
| mmooss wrote:
| > windows was developed before security was important
|
| That was a long time ago, the 1980s and 1990s. Windows has
| been transformed since then, particularly with Windows 10.
| snvzz wrote:
| >SeL4 has a fully verified kernel but it doesn't do
| virtualization yet.
|
| It very much does virtualization. And, as far as I am aware,
| it does it better than any other OS.
|
| Incidentally, seL4 just had its seL4 Summit 2024[0].
|
| 0. https://www.youtube.com/playlist?list=PLtoQeavghzr0ZntMmRP
| wg...
| throwaway48476 wrote:
| But is the virtualization component fully verified?
| akira2501 wrote:
| > The problem is that windows was developed before security
| was important.
|
| I disagree. Plenty of systems have added security as an
| afterthought and were just fine for the effort.
|
| The problem is most people just want to play video games.
| They don't care about security. They don't actually want
| security if it frustrates their efforts to play games or
| reduces the computing power available for the game.
|
| Look at houses. We could have amazing high security locks
| everywhere if we wanted. We don't. We don't perceive
| ourselves as needing them. It turns out "tamper evident" is a
| decent level of security for the real world and allows homes
| to be partially secure while being totally livable.
| Hilift wrote:
| The driver signing blacklist file DriverSiPolicy.p7b had not
| been updated for years. It took a CERT analyst (Will Dormann)
| to ask why in 2022. It's being updated regularly now, but WTF.
| https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
| marcosdumay wrote:
| In principle, there's something about Windows object system
| being much a much more complex abstraction than Unix's streams.
|
| But the reality is not that. Windows is just surrounded by
| layers and layers of bad code with atrocious interfaces. Any
| architectural weakness doesn't even register.
| gosub100 wrote:
| - The EULA absolves Microsoft of any liability whatsoever. So
| they share in none of the risk. Imagine if physical items were
| like this: hit one bump and your pickup is destroyed. Scissors
| fall apart irreparably once they contact any material that's
| not paper.
|
| - MS putting backwards compatibility (mainly done for business
| customers) above everything, at all costs. The peanut butter
| factory in Indiana that's been running WFW since '89 must never
| be inconvenienced, even if it means tens of thousands of people
| have to take their brand new computers to the shop (at their
| own cost!) multiple times per year because of spyware
| infections.
|
| - Not valuing innovation. A culture where engineers are just a
| necessity to keep the money-making machine running. All the
| excitement was drained about the end of the '90s. They made a
| couple nominal hits with the Surface, Xbox, and Azure, not
| going to discount that.
| the_arun wrote:
| Hard to believe Microsoft is disagreeing when there is a demo.
|
| In that Vimeo account there are ton of other security
| discoveries. Eg WhatsApp running python script. Is this real or
| scam?
| 9029 wrote:
| Well the demo is showing a crossing of something that ms has
| defined to not be a real security boundary: "Administrative
| processes and users are considered part of the Trusted
| Computing Base (TCB) for Windows and are therefore not strong
| isolated from the kernel boundary." [0]
|
| Another recent case:
| https://arstechnica.com/security/2024/03/hackers-exploited-w...
|
| [0] https://www.microsoft.com/en-us/msrc/windows-security-
| servic...
| morpheuskafka wrote:
| On the Linux side, SELinux which sets guardrails on the root
| user at the kernel level is mandatory for protecting
| classified information. Thus, there is most certainly a
| security boundary between root, let alone regular users with
| "admin" groups/perms, and the kernel.
|
| How can Windows, which is used all over the government, have
| a policy that admin users can do whatever they want with the
| kernel without it being a security vulnerability?
| dwattttt wrote:
| Because their policy is to not give admin to a user if you
| don't want them to have control of the computer?
| jeroenhd wrote:
| 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.
| mrinfinitiesx wrote:
| The owner of this website (www.bleepingcomputer.com) has banned
| your IP address (IP)
|
| K.
|
| edit: VPN, ssh -D to vps & socks5 localhost worked. Can't have
| anything anymore.
| alpaca128 wrote:
| If you have a dynamic IP it was probably banned because of
| someone else who had it in the past.
| dkasper wrote:
| Haunted IPs are a thing, same as the haunted domains article
| also on the front page right now!
| https://news.ycombinator.com/item?id=41951131
| worewood wrote:
| With widespread CGNAT and the exhaustion of IPv4 addresses
| this will become more and more common each day...
| snvzz wrote:
| Headscale, the open source backend alternative to tailscale,
| which frontend is open source to begin with, is worth looking
| into.
| ajross wrote:
| Seems like the attack is suspiciously simple: Fool the update
| process into installing _old_ versions of kernel components with
| known vulnerabilities. I 'm no expert, but surely MS has already
| thought about this and has a blacklist or revocation facility or
| whatever?
|
| Is the root cause here an OS design issue or just a process
| failure where they failed to note the broken/bad hashes in the
| correct spot? The latter is much easier to fix, but the (slightly
| spun, as always) security announcement seems to claim the former.
| SoftTalker wrote:
| Maybe they have to allow downgrades because enterprise users
| will insist on being able to downgrade if an update breaks
| something?
| marcosdumay wrote:
| Windows automatically downgrades when an update breaks
| everything...
|
| And then schedules the update again...
|
| What is a fairly common thing to happen...
| bubblesnort wrote:
| > possible by gaining kernel code execution as an administrator
|
| The root user can install rootkits as usual. Don't forget to
| brand it a cool name.... Oh wait: > The
| researcher published a tool called Windows Downdate
|
| There you go, here's your 0xF minutes of fame, well played.
| jojonas wrote:
| The concept that there is a root/superuser account that can do
| anything they like is quite a common one, but it is an OS
| design choice. Any user account is just an object in the
| operating system and one can as well design an OS that enforces
| certain rules against all user accounts, even if that means
| limiting superuser accounts.
|
| Legitimate reasons I can think of would be for example to
| protect certain secrets even in the event of an administrator
| compromise (like a TPM) or just to prevent administrators from
| accidentally messing up their systems to an extent that they
| wouldn't boot. Another (more controversial) goal is to enforce
| DRM.
|
| Anyways, that's exactly what Microsoft is attempting to do with
| Windows: the OS tries to prevent administrative accounts from
| interfering with the kernel/installing rootkits (for whatever
| reason).
|
| Also note that it's always important in this discussion to
| differentiate between administrative user _accounts_ (in the
| OS) and "administrators" (people) with physical/hardware
| access.
| thrtythreeforty wrote:
| I'm kind of with Microsoft on this one: the administrator can do
| arbitrary things to the computer, film at 11. Is there a nuance
| that I'm missing that raises the severity of this?
|
| See also Raymond Chen's summary of this class of attack:
|
| https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
| kgeist wrote:
| My thought exactly. If someone is already able to replace
| arbitrary DLLs on the system (a precondition for this "exploit"
| to work), all bets are off, and their ability to bypass driver
| signatures is probably the least of your concerns.
| jeroenhd wrote:
| In practice there's no good defence against this, but Windows
| is designed to protect itself against these kinds of attacks
| if all components work together. With secure boot + driver
| signature validation + DLL signature validation, you can't
| just run any code by putting it in a DLL file. You're not
| hacking any normal computer by replacing user32.dll with
| virus.dll.
|
| Downgrade protection is quite a hard problem to solve without
| at least breaking the automatic recovery tools. In theory
| Microsoft could register the versions of every system file
| somewhere, sign+hash that, and store it some place secure,
| but then they'd need to deal with reverts of system
| components after a failed update or restored system images
| becoming unbootable.
|
| In practice, I don't see the use case for this attack,
| though. You can just put a legitimate, signed driver with a
| known exploit inside your executable and load that. Microsoft
| chooses to keep unpatched, vulnerable drivers rather than
| break hardware support for millions of users.
| quotemstr wrote:
| So the kernel is enforcing file sharing rules (mandatory locking,
| in effect) by scanning on open all open file handles for
| conflicting mandatory locks, but doesn't check for memory
| mappings of these files with conflicting permissions. Oops. Seems
| like a straightforward fix though.
|
| It's worth noting that Linux just got rid of its last vestige of
| mandatory locking. Now you can write a loaded executable without
| getting EBUSY. Interesting how exactly the same feature on one OS
| can be a load bearing part of the security infrastructure and on
| another OS legacy crud to be deleted.
| fullspectrumdev wrote:
| So what's interesting is MS say that UAC isn't a security
| boundary. Which is some users to admin.
|
| Then they say admin to kernel (in this case) isn't a security
| boundary.
|
| While also saying that driver signing enforcement is a security
| feature.
|
| Which is what's being bypassed here.
|
| But they claim in this case it's not crossing a security
| boundary.
|
| Please make sense.
| prettyStandard wrote:
| This is a value system disagreement.
|
| I have a theory that there's basically two types of
| disagreements, disagreements on definitions, and disagreements
| on value systems.
|
| In this case Microsoft values downplaying this issue, so when
| that is at the top of their value system their decisions should
| make sense following that.
|
| Since this is just a pet theory I'm very interested to hear
| critiques on it.
|
| Disagreements on definition are a little bit easier, because
| then you can just talk about the definitions and resolve your
| differences there... For example let's say IDK You're trying to
| sort out how to design a software system, and everyone is
| speaking in terms of design patterns, but they haven't yet
| spelled out the details of what those designed patterns are,
| then that could probably lead to a lot of confusion if when you
| say A I think of A', and another person is thinking of A''.
| Buttons840 wrote:
| I like this. I first noticed this with gay marriage. 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'". For these people, it was all about the
| definition of a word.
|
| Other people opposed gay marriage because it went against
| their values. No matter what you wanted to call it, they were
| opposed to gay people living together and sharing their
| lives.
|
| I chose this example because it's the first time I noticed
| that some disagreements are about the definition of a word,
| and it's an especially clear example of that. It's silly how
| huge disagreements about a single word can become.
|
| There are also people who disguise their value disagreement
| as a definition disagreement. This is a form of bad faith
| arguing.
| BJones12 wrote:
| 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.
| whatshisface wrote:
| Some of this may be due to a desire to transform an
| illicit desire for authority ("I declare that I shall not
| pay out a bounty") into a legitimate contest ("this bug
| is not a bug because I desire to clarify our communal
| understanding of the concept of a bug...").
| hggigg wrote:
| It makes sense if Microsoft's strategy is having a flexible
| self-serving value system.
| layer8 wrote:
| This assumes Microsoft being a singular entity with a single
| set of values (or even a single set of definitions), which I
| believe is an incorrect premise. It's misleading to think of
| organizations as if they were a single mind. (Not to speak of
| the fact that it's quite common even for singular minds to
| have inconsistent values and beliefs.)
| rawgabbit wrote:
| Socratic logic argues you must first agree on the meaning of
| terms and definitions. Next is determination of what the
| facts are. Lastly is logical arguments. Guess which part is
| the most difficult?
|
| Religious logic is like this. It presupposes a greater
| mystery that has been partially revealed to us. It also
| presupposes that our fallible logic cannot on its own
| understand the truth. In other words it defines faith as
| believing in the greater truth even if the world and every
| one says we are foolish to believe in such fairy tales.
| prettyStandard wrote:
| 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?
| dataflow wrote:
| > This is a value system disagreement.
|
| Sorry, this is not a value system disagreement. It's
| definitions, pure and simple. As I mentioned in my sibling
| comment, the definition (and thus boundary) has been pretty
| sharp and clear for decades: the user group. If you're a
| standard user, such as in the "Users" or "Guests" groups,
| you're behind the boundary. If you're in the "Administrators"
| group, you're already past it.
|
| That's all there is to it.
| prettyStandard wrote:
| 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.
| dataflow wrote:
| >> 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.
|
| I take it you're insinuating I'm one of these people
| here?
|
| Hasn't group membership been the defining security
| boundary in Windows for over two decades?
| pdonis wrote:
| _> 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.
| dataflow wrote:
| > The issue is not that people don't understand how MS
| defines what is and is not a security boundary.
|
| That's a communication failure, not a value system
| disagreement.
|
| > 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.
|
| Just because two entities differ on their values that
| doesn't mean everything they disagree on is their values.
|
| In this case, the fact that users and Microsoft differ on
| what constitutes a security boundary is 100% a
| definitional disagreement.
|
| Now MS obviously has had their own values and reasons for
| _not_ establishing other security boundaries people would
| like, and _that_ is a value system disagreement. But even
| if their values agreed with yours and they hated the
| current design just like you, the fact of the matter
| would still be that user account groups _are_ the
| boundaries in the current design, and that would still
| imply this isn 't crossing a security boundary, making
| the disagreement on that definitional.
| quotemstr wrote:
| UAC _in practice_ doesn 't function as a security boundary, and
| to make it one would so inconvenience users that they'd just go
| to other OSes.
|
| Both UAC and sudo are just OS level cookie dialog boxes. Let's
| get rid of all three.
|
| 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.
| BSDobelix wrote:
| >sandbox apps
|
| This is about drivers...
| quotemstr wrote:
| 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
| cruffle_duffle wrote:
| Drivers can be whatever but their effect is usually
| global not for a specific user or app. So when you
| update, say, a graphics driver you are updating a shared
| resource used by everything in the system.
|
| You can run that display driver in whatever security
| context you want be it "root" or its own constrained
| context but that doesn't change the fact that other
| things in the system, running under their own security
| contexts, are feeding that driver stuff. And given there
| is generally only one display output, or sound output, or
| whatever, all things in the system have to use it for
| output, making it more privileged than the rest.
|
| Whatever security context a display driver runs in, that
| context by requirement has to be more privileged than
| whatever context your browser or a calculator app runs
| in. To make changes to that shared display driver, you
| need to cross some kind of security boundary and it would
| be nice to make sure the user is who they say they are,
| they are allowed to do the requested action and they are
| made aware of the change. Thus methods like UAC and sudo.
|
| I'm not sure how you can escape that. Removing sudo and
| UAC doesn't change the fact that something wants to mess
| with a shared resource running with some kind of elevated
| privilege.
| anthk wrote:
| Check Hurd's daemons and Plan9/9front (and Hurd's)
| namespaces.
| gosub100 wrote:
| I used to openly hate the UAC box but now I do recognize
| it as a low cost, high-return feature that interrupts
| people to force them to recognize that something serious
| is about to happen. It probably works fine for families
| and small businesses where it gives non-technical people
| and opportunity to back out of whatever they were doing,
| especially if they didn't realize or intend to change
| something.
| BSDobelix wrote:
| >drivers should be apps too (Redox and others (even macOS
| partially) get this right)
|
| Man i stop here since you don't even know what a driver
| is, and no, nor Redox or macOS can do anything against a
| bad/hostile but signed driver.
|
| But you obviously don't know what drivers are
| (hint..communicating directly with hardware)
| quotemstr wrote:
| Have you ever heard of an IOMMU? Talking to hardware is
| not a god mode cheat code. It's long been feasible to
| limit a drive's access to hardware it's supposed to
| manage. Why should I let my NVMe driver talk to my NIC?
| It shouldn't even be able to see plaintext disk sectors!
| If you're going to make sweeping statements about others
| being incorrect, it would behoove you to become familiar
| with the material.
| BSDobelix wrote:
| Hey i stop here, even your first comment was god-mode
| wrong, sometimes it's better to just write nothing then
| to call drivers "apps" and clearly not knowing the
| difference between user and kernel-mode.
|
| Look have fun and keep telling others that macOS and
| Redox has drivers who are apps...clown-show starts in 3 2
| 1
| quotemstr wrote:
| You're clearly interested in operating systems. I hope
| you learn about them one day so you can contribute to
| one. You might want to start with, e.g. infiniband
| drivers, which somehow allow programs to communicate
| "directly" with hardware without having unlimited
| privilege. There's a lot more to OS design than a
| user/kernel dichotomy, and user mode can do more than you
| think.
| BSDobelix wrote:
| >infiniband drivers, which somehow allow programs to
| communicate "directly" with hardware
|
| At least you understand what drivers do, like my printer-
| driver or GPU-Drivers
| tsujamin wrote:
| > Both UAC and sudo are just OS level cookie dialog boxes
|
| To be fair, that's misconstruing UAC and CredUI/Secure
| Desktop a little. There probably is merit in switching to an
| isolated desktop session when seeking consent, or user
| credentials, despite the fact that UAC/the AuthZ part within
| a user account has flaws. I think another issue is probably
| that most user's exposure to UAC is on machine's they're the
| sole user and administrator of; it's a different ballgame in
| enterprises where the end user is probably the least
| privileged principal logged into a particular PC.
|
| Windows et al have Sandboxed apps, but which apps and which
| users should be allowed to do system-level confirmation type
| changes? iOS and Android are (for the most part) on single
| user devices, you still need some sort of AuthZ system to
| decide who and which apps can change what on multi-user
| systems.
| yndoendo wrote:
| I don't understand why moving to system designs that require
| exploitation of the accessibility layer to turn a device into
| something semi functional.
|
| Those OS go out of the way preventing features that hinder
| usefulness of the devices. Such as recording phone calls.
| Allowing the blocking of network IP addresses and domains.
| While supplying monolithic integration that is limited to all
| but the OS maintainers.
|
| Google dialer does not allow for integration of 3rd party
| contacts. It is built around Google remote storage. Apple
| Messenger doesn't allow for conversing with non Apple device
| users except for insecure text messaging while promoting
| cyber bullying with green vs blue text.
|
| Another security and business risk of using Google or Apple
| for content storage with limited recourse when they lock out
| our accounts.
| kaoD wrote:
| 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.
| miki123211 wrote:
| > 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.
| layer8 wrote:
| 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.
| acka wrote:
| 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.
| noinsight wrote:
| > UAC _in practice_
|
| UAC is not a security boundary _by design_.
|
| > It's important to be aware that UAC elevations are
| conveniences and not security boundaries ...
|
| - Mark Russinovich, Microsoft Corporation [1]
|
| [1] https://web.archive.org/web/20080101143433/http://www.mic
| ros...
| dataflow wrote:
| > Please make sense.
|
| They do make sense. You're missing something critical in the
| argument.
|
| > So what's interesting is MS say that UAC isn't a security
| boundary. Which is some users to admin.
|
| This is incorrect. UAC is for already-admin users; it's not
| "some users to admin". The security boundary exists around
| standard users, not admin users.
|
| This might not be what you _like_ , which I totally get, but it
| does make sense. If you want a security boundary, don't create
| a user in the Administrators group.
| akira2501 wrote:
| > If you want a security boundary, don't create a user in the
| Administrators group.
|
| As a user aren't you essentially forced to this to have a
| usable desktop experience? I mean, sure, there is a
| boundary.. but it's drawn rather carelessly around the entire
| stack.
| dataflow wrote:
| Depends what you're doing?
| akira2501 wrote:
| Using any non Microsoft software.
| dataflow wrote:
| Like what? Chrome? Firefox? Acrobat? Photoshop?
| tsujamin wrote:
| I'm the only local admin on my mother's laptop, she's
| never noticed and I've not logged in to do anything in
| over 2 years.
| dataflow wrote:
| Yeah, exactly. It really depends what you're doing. If
| you're doing software development as part of your job,
| that's obviously going to require admin privilege way
| more often than if you're answering emails.
| taberiand wrote:
| Even doing extensive software development - including
| WSL, Docker, SQL Server, and other services needing low
| level access - Admin privileges usually only come up when
| installing, updating or uninstalling software.
| fireflash38 wrote:
| Only problem is that certain things update constantly
| (VSCode)
| dataflow wrote:
| > Only problem is that certain things update constantly
| (VSCode)
|
| Can't you just install it at the user level?
| https://code.visualstudio.com/docs/setup/windows#_user-
| setup...
| pdonis wrote:
| _> Can 't you just install it at the user level?_
|
| Sure, if you want your ordinary non-admin user to have
| write access to the executables, which makes it a lot
| easier for some malicious piece of software to hack them
| since it no longer needs to get root permissions.
| josephcsible wrote:
| If malware is already running as you with the ability to
| write to your files, what does it gain by Trojaning your
| VSCode to do bad stuff instead of just doing the bad
| stuff directly?
| dataflow wrote:
| > Sure, if you want your ordinary non-admin user to have
| write access to the executables, which makes it a lot
| easier for some malicious piece of software to hack them
| since it no longer needs to get root permissions.
|
| As if non-admins have no way to create a new executable
| and run those instead? Windows has a million ways to run
| code, both visibly and invisibly. Why would malware
| prefer to trash an executable that the user relies on for
| daily work and risk revealing its presence so quickly?
| tsujamin wrote:
| Agree, but also you don't need the entire session running
| as admin. I usually leave a terminal and IDE running as
| an admin user with the rest of the session low-priv.
| Obviously some security weaknesses there but it's better
| than having a whole admin session.
| magicalhippo wrote:
| 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.
| jazzyjackson wrote:
| Really threw in a wrench in my day once when I realized
| guest accounts were disabled years ago, I just wanted to
| hand a laptop over to a 3 year old to watch paw patrol
| and to create a new user it was having me go through a
| Microsoft account flow complete with 3 security
| questions. I didn't feel any safer afterwards.
| pdonis wrote:
| _> it 's usually enough to install it outside of Program
| Files_
|
| Meaning, in a user's home directory somewhere? That's
| even worse, because now that user has write access to the
| executables. Which makes it even easier for some
| nefarious piece of software to pwn those executables,
| since they don't even need to get root permission.
| jpc0 wrote:
| But the executable can still only run in the context it
| exists even if it is compromised. This is akin to
| SELinux...
|
| You cannot compromise an executable run without
| permission and magically get Administrator or some higher
| privilege level without another exploit. Sure that
| specific user's data may be compromised but in the end
| the system remained secure.
|
| Also keep in mind Microsoft by default has a ton of
| sandboxes and checks on those applications which will
| likely get caught as well should that compromised
| application try to access something it shouldn't.
|
| I don't personally know of a mass security event
| involving Windows that cannot be chuaked up to failing to
| implement security updates. Sure Microsoft has some
| massive security issues but in general their track record
| isn't as bad as people try to make it out as.
|
| There are enough reasons to hate windows without making
| up new ones.
| wongarsu wrote:
| 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
| taberiand wrote:
| And commonly you don't switch to the admin account
| outside of entering the admin credentials when the UAC is
| displayed.
|
| There are still too many applications that unnecessarily
| require admin credentials to do _something_ (I 'd love
| the system to report exactly what the app is trying to
| do) but it is a lot better than it used to be
| hu3 wrote:
| I actually like UAC.
|
| Specially when it asks me if I should allow HP printer
| driver to download new updates. No thanks I'll keep the
| minimal driver Mr. HP.
| dwattttt wrote:
| 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.
| Melatonic wrote:
| 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.
| pdonis wrote:
| _> this is the default way Linux works (not entirely the
| same but similar enough) with sudo_
|
| Kinda sorta. Here "not entirely the same but similar
| enough" means "doing the one major thing that Linux does
| not force you to do", namely, creating a _whole separate
| user account_ just so that MS can make the braindead
| claim that a security boundary isn 't being crossed when
| you enter admin permissions from an Administrator
| account. On a Linux system you only need to create _one_
| user account, and put it in the sudoers group, and Linux
| then properly treats every attempt to do something with
| sudo as crossing a security boundary and acts
| accordingly.
| pdonis wrote:
| _> If you want a security boundary, don 't create a user in
| the Administrators group._
|
| Which makes no sense. The fact that a user is in the
| Administrators group does not mean every single action they
| take should automatically have root permissions, or that
| using the UAC prompt to get root permission for a particular
| action shouldn't be treated as crossing a security boundary.
| On my Linux system, the fact that my user is in the sudoers
| group doesn't mean Linux just throws up its hands and says,
| oh well, can't enforce any security boundary now for what
| that user does. MS is simply punting here. But of course
| Windows was never designed for security, and what braindead
| security it does offer was bolted on as an afterthought.
| dataflow wrote:
| > 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.
| doctorpangloss wrote:
| I've learned that if you want bugs fixed in Windows, pay for
| professional support. Same as corporate-managed open source
| software. The real question is why people bother doing free
| security research work for Microsoft, instead of spending their
| intellectual energy making desktop Linux better.
| ospray wrote:
| They have always had these contradictions. I think it's because
| they know there are lots of bypasses for all of them.
| quotemstr wrote:
| It's also interesting how on both Windows and Linux normal-
| privilege local accounts are, practically, root equivalent. In
| Linux, we train people to type "sudo" in front of anything system
| relevant. On Windows, we train users to click through UAC
| prompts. When was the last time sudo said "no" to somebody for a
| reason other than a password typo?
|
| (UAC is marginally better than sudo: UAC is system managed UI,
| while sudo is just a program. An attacker can plug in a malicious
| shell alias for sudo and steal your password.)
|
| IMHO, it'd be more convenient for users and more reflective of
| actual security posture to get rid of both sudo and UAC (in the
| default setup of course) and stop pretending that there's a firm
| security boundary between root and the primary human local user
| account.
| a2128 wrote:
| On Linux, most modern user-facing applications are using polkit
| instead of sudo. You can actually just use pkexec instead of
| sudo in the terminal as well.
|
| Instead of just running arbitrary commands as root,
| applications can use specific pre-defined actions like
| "org.freedesktop.udisks2.filesystem-mount". This shows a nice
| localized message to the end user about what the app is trying
| to do, so they can decide whether to allow it or not. The
| system administrator can also configure certain actions to not
| even require authentication, useful for e.g. flatpak updates,
| or to block certain actions altogether.
| adrian_b wrote:
| On Linux, I do not install sudo, because I do not need very
| often to become root, and when I need that I usually want to do
| multiple operations.
|
| I believe that "sudo" is useful only on multi-user computers
| (including company-owned and company-managed computers), where
| the administrator may want to give to some users the power to
| do only a restricted set of privileged operations.
|
| I always use a different user account than root, mainly not for
| security, but to avoid any accidental mistakes, when I could
| delete or overwrite other files than intended.
|
| I believe that this is a good enough reason to justify the need
| to type infrequently a password in order to change roles.
| dwattttt wrote:
| I think an equivalent way to phrase this that feels very
| different is: "On both Windows and Linux the default installed
| users are, practically, root equivalent". I guess on the basis
| that the user performing the installation should be in control
| of the system (I mean, they are; they could've just not done
| the installation. Where are your access controls now, blank
| system!)
|
| > When was the last time sudo said "no" to somebody for a
| reason other than a password typo?
|
| Sudo doesn't say no to people, much like UAC doesn't say "no"
| to people. In both cases, people (admins) are meant to say "no"
| when they don't expect to be performing an administrative
| operation. People who are not admins and yet need to do such
| operations need an administrator to authorise it.
|
| In both cases, if it's not a single-person system, whoever is
| setting the machine up should be setting up limited accounts
| for regular use.
| jeroenhd wrote:
| In my experience (on Gnome at least), Linux is moving towards
| Windows-style sudo protection. It lacks the "press
| ctrl+alt+delete to verify" trick.
|
| Windows has the advantage that you don't need to script
| everything. You can wrap
| `runas`/`System.Management.Automation.PSCredential` around
| every other tool if you want to, you just don't need to in most
| cases.
| TheRealPomax wrote:
| it also allows tampering with Windows 11 to actually make it a
| better OS because it bypasses all the Microsoft lockdown
| bullshit, but let's focus on the rootkits instead.
| Sakos wrote:
| I've noticed that a surprising number of people here on HN are
| in favour of locking down Windows and preventing any kernel
| access at all to Windows users. It reeks of the "think of the
| children" arguments.
| lock_it_down wrote:
| No, as a user which has no need for kernel access I want it
| locked down so the real things I care about, my data, is more
| secure.
|
| It's called security in depth.
| Sakos wrote:
| 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.
| de6u99er wrote:
| When I have to use Windows I always assume the computer has been
| compromised.
| wslh wrote:
| Wow! I remember the hard time we all had at [1] (doing deep
| packet inspection drivers for [2]). when Microsoft first required
| driver signing in Windows. The workflow seemed, at first glance,
| even tougher than getting an app approved on the Apple Store,
| with documentation that was far from clear. Personally, this
| feels like a huge setback considering the resources companies
| have poured into complying with Microsoft's requirements, only to
| see it exploited in this way. Of course, vulnerabilities are
| always out there, but it would have been reassuring if someone
| had uncovered this one earlier. Kudos to Alon Leviev and
| SafeBreach for discovering it.
|
| [1] https://www.nektra.com/
|
| [2] https://www.verizon.com/business/en-
| nl/products/security/man...
___________________________________________________________________
(page generated 2024-10-26 23:01 UTC)