If you are not on the list (Toshiba) you are fine.
There was 23 vulnerabilities in the UEFI program. Most of them are connected somehow with System Management Mode (SMM feature). This gives an UEFI user root privileges inside the UEFI despite he having normally normal user privileges while using an OS (Windows or Linux, it wont matter).
While you cant immediately for example transfer money from someone elses account into your own by simply having root user access through UEFI, you can still use UEFI to create clever routes of attack onto that computer to use them later by enabling some BIOS features which were disabled and whatnot.
At least this kind of attacks are possible: -elevated user privilege inside an OS -put garbage onto RAM (this will result in crash or writing bogus information on HDD thus corrupting files) -crash device drivers and thus devices
Many of the PC manufacturers are right now checking out if their motherboards are compromised.
>Most of them outsourced the UEFI part for the devices they sell from a thirdparty source, a UEFI maker company
You mean Mossad and CCP intern plant created vulnerabilities have been found out.
John Adams
google web cache probably can also show the site
Zachary Bell
intel smm ring negative backdoor at-spi / accessibility features / all bsd, linux, windows, mobile are exploitable with these features for "blind impaired or disabled" it literally accesses all your entire screen (narrator, text to speech etc.) so it's the way to go for all adversaries for GUI spyware. basically in lay this is "log4j but operating systems are all affected" they really LOVE remote access of computers the chain of command remote execution is: >cloud network >-> your pc >-> pozzed network stack >-> cpu allows ring negative backdoor >-> ring negative bypasses the OS security through accessibility features >-> adversaries get all your shit recently it's already been a success, with the dawn of pipewire-wayland screensurfing exploits had never been so easy! polkit exploit has a workaround ;-)
>ring negative bypasses the OS security through accessibility features what? why and how would accessibility shit have access to anything below ring 0?
Blake Sanchez
nevermind I'm retarded, you use the accessibility shit from ring negative because there's still the OS in the way
Isaac Collins
how did a simple debug logger (log4j) literally allow zero-click remote code execution? accessibility is even worse, it can access all your entire screen, it can "narrate" the text on the screen. all it needs is a trigger and finally loonix users should switch to wayland so it would be easier to access their screens. tired of vnc-remote-desktop access over some loonix user and end up trapped in a black teletype screen. wayland should fix this. ring negative zero? LETS FUCKING GOOOOOOOOOO
Hunter Taylor
>ring negative >accessibility features Hello, /x/, and go back.
Levi Torres
I was looking for a new laptop but these news are a big redpill, I bet 90% of affected devices won't get a patch for that, also you need fucking Windows for bios updates so every time something like that comes out you have to wipe your whole drive just to update bios, what the fuck
Carson Nelson
Ring negative exploits are abused in the network binaries' bugs along with the pozzed network stack NOT through accessibility. Accessibility features is just a way to easily grant a rootkit enough privileges without extra handiwork.
Landon Young
UEFI was always pozzed M$ garbage, see also: SecureBoot. BIOS isn't great from a technical standpoint, but UEFI is an order of magnitude worse.
Andrew Gonzalez
>M$ garbage Really shows how much you know.
William Nguyen
>MUH VULNERABILITIES >requires attacker to run native code on the system not my problem
Liam Martin
>PE as the executable format >FAT as the filesystem You do know Microsoft and Intel are in bed, right? Sure, it's not a Microsoft standard, but Microsoft doesn't produce hardware in the first place.
Jace Morgan
>PE as the executable format >FAT as the filesystem Nothiing wrong with PE and FAT, they are the most commonly used executable file format and the most widely compatible filesystem for x86/x64 devices. What else should they have used?
Jackson Wright
Not a schizo so im not worried
Benjamin King
>BIOS isn't great from a technical standpoint
Yes it is not good tech, and certainly not modern, but at least its somewhat secure
Caleb Torres
The very idea of implementing a loader and filesystem driver in firmware is abhorrent in the first place. FAT is more or less standard, sure, but if you're standardising boot you do have the ability to specialise, it's not like you're breaking any backwards compatibility anyway.
Logan Hernandez
MBRbros, it’s our time again…
Adrian Phillips
>>PE as the executable format OK. >>FAT as the filesystem Fat16 is the easiest FS to implement among modern ones, don't know about those abandoned. U-boot uses it. OS dev hobbyists start with its driver. Also its patents have expired since, so it's an easy choice.
Blake Barnes
when will all this goddam bullshit stop literally none of this happened during the bios era
Oliver Nelson
>The very idea of implementing a loader and filesystem driver in firmware is abhorrent in the first place Why? Instead of every OS rolling their own bootloader they can just use the UEFI services and just go Load("muhKernel.bin") and Execute("muhKernel.bin") instead of re-implementing the same shit.
Leo Martin
Filesystems aren't inherent to computers nor data storage, they're a software abstraction; the firmware shouldn't be responsible for software abstractions like this. There's not really any need for an OS to implement its own bootloader unless it has very special needs. If you're on an embedded platform UEFI is a hinderance, most of those platforms have their own boot methods but that just goes to show that UEFI is hardly "unified".
Cooper Thompson
this will be used by microsoft to promote pluton chip for cloud-to-chip firmware updates.
Brayden Williams
>Filesystems aren't inherent to computers nor data storage, they're a software abstraction; the firmware shouldn't be responsible for software abstractions like this. TL;DR you have autism. The system firmware does need to be able to read and write files, for example, to load and save UEFI profiles to USB sticks, to take screenshots of the UEFI configuration screen, and to update the firmware from USB. Why not make those functions accessible to bootloaders so they don't need to implement that shit again? >There's not really any need for an OS to implement its own bootloader unless it has very special needs. So if I make a new shitty hobby OS, what bootloader should I use? >If you're on an embedded platform UEFI is a hinderance Dude I don't care. Embedded platform designers can use whatever boot method they want, so if it's a hinderance it's their own fault for designing it that way. >that just goes to show that UEFI is hardly "unified". More autism.
Noah Green
>security vulnerability that's only realistically usable by the MOSAD and the CIA literally none issue.
