"I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again. "
Pretty much everything you could want is available for free from trusted repositories, and so there is little or no incentive to download and install warez or other pirated software that may have been tampered with.
Even in a pipedream world where everybody ran Linux, you wouldn't be getting major label games for free. There'd still be piracy for pr0n, movies, games, high-end applications that regular people don't need but do want, et cetera. And your regular Joe Moron won't stop downloading (trojanized) codecs in order to see his warezed pr0n, and even if no local privilege escalation exploit is used, Joe Moron still won't think twice before allowing the trojanized codec root access.
And even in a 100% securely locked down OS, Jane Stupidcunt will still enter her email+password combo on hxxp://funny-party-pictures.rapemecozimstupid.com to see "OMG YOU WERE SO DRUNK!" pictures, her address book will be harvested, and the email spamming will happen elsewhere.
Or we could, you know, just use more secure operating systems.
Won't work as long as there's still regular people using computers. Yes, for XP and below the default user account has administrative privileges, but Vista and upwards it's a LUA - the infections you get there are usually from stupids clicking "yeah sure, rape me anally" on the UAC prompts, not by malware doing sneaky privilege escalation.
A rootkit wouldn't need to do the same level of virtualization that a full-blown hypervisor does - access to devices could be let through directly, filtering of disk access to hide the rootkit is done by intercepting OS drivers anyway. Running the rootkit as a hypervisor would still allow the rootkit to hide the memory it's operating in from the OS, as well as not allowing the OS full ring0 access.
I'm pretty sure this wouldn't give a noticeable speed hit for regular users, and would still be pretty darn effective.
...and sudo probably isn't even going to be necessary, there's surely a fair amount of local privilege escalation bugs that haven't been detected yet. Yep, they'll get patched eventually, but a "Joe Clueless" won't be updating his system and thus won't get the fixes:)
Boot the machine from a livecd, and don't have it connected to the network. If you're afraid of physical damage, use some old piece of junk; never seen an IT department that didn't have old junk lying around.
For destruction? Your IT department is so technically challenged they can't figure out how to access a USB stick without risk of running malware from it? O_o
How many native developers will be working on browser teams, though?
While I don't personally believe everything will move to web apps, a lot is. Some of it for good reason, some of it because CEOs and other stupids thinks it's a good idea... so it's happening.
But hasn't it always been like that in IT? If you cling on to one old platform and aren't willing to learn new technologies, you're eventually going to become irrelevant?
And in order to compromise the operating system with Flash or HTML5 Canvas, you have to find a buggy 2D driver. All I get out of this article is that 2D drivers are more mature than 3D drivers.
Indeed.
The 2D APIs are less complex, they have a smaller attack surface, and you don't get direct access to the OS's 2D API from the browser (thinly wrapped access to Windows GDI would be almost as bad an idea as thinly wrapped access to OpenGL).
Of course it's not native code, and of course the high-level API doesn't offer DMA access. Just like JavaScript, Java, Flash, Adobe Reader (et cetera) doesn't come with ExploitBufferOverflow() or LocalPrivilegeEscalation() functions... catch my drift?:)
WebGL is a more complicated API than, say, the 2d context for the html5 canvas, and it's one big step closer to a graphics API that was written exclusive with speed in mind.
However, there's quite some differences between the APIs used by normal browser rendering, the 2d canvas context, and finally the WebGL canvas context. If you have followed Mozilla's work on GPU-accelerating Firefox, you should know that even "controlled" usage of the 3D APIs can be troublesome... and with WebGL, you pretty much remove the "control" part.
If WebGL is successful it will help to break the domination of DirectX among the desktop graphics hardware vendors and cause developers to look beyond the Microsoft romper room.
Ah yes, WebGL + JavaScript will displace native C++ code combine with OpenGL/DirectX? (That'd be a wet dream of Intel and AMD - even with JS JIT advances, we'd need quite more powerful CPUs).
It will require a couple of incidents before Google, Mozilla, et al. concede this and lock down WebGL, taking it off the table as a viable attack vector. Eventually they will. Bank on it.
Google are cool, but they aren't superhumans. Some things just aren't 100% securable.
It isn't a security vulnerability when Silverlight gains access to the GPU. Hhmmm.
It says "immedate mode graphics", it doesn't say "thin wrapper around DirectX" or "you can run shader code directly".
It's very possible it might in fact be a thing wrapper around DX, in which case I'd be the first to cry bloody murder... but you can't deduce much from just that statement.
It's not really about video memory, it's about shader code and driver bugs - which can (potentially) do a lot more damage than just reading video memory.
Slashdot Mirror
Wrong.
"I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again. "
- http://en.wikiquote.org/wiki/Bill_Gates
If I had any mod points left, you would be getting them :)
Yep, do a little googling :)
Pretty much everything you could want is available for free from trusted repositories, and so there is little or no incentive to download and install warez or other pirated software that may have been tampered with.
Even in a pipedream world where everybody ran Linux, you wouldn't be getting major label games for free. There'd still be piracy for pr0n, movies, games, high-end applications that regular people don't need but do want, et cetera. And your regular Joe Moron won't stop downloading (trojanized) codecs in order to see his warezed pr0n, and even if no local privilege escalation exploit is used, Joe Moron still won't think twice before allowing the trojanized codec root access.
And even in a 100% securely locked down OS, Jane Stupidcunt will still enter her email+password combo on hxxp://funny-party-pictures.rapemecozimstupid.com to see "OMG YOU WERE SO DRUNK!" pictures, her address book will be harvested, and the email spamming will happen elsewhere.
Or we could, you know, just use more secure operating systems.
Won't work as long as there's still regular people using computers. Yes, for XP and below the default user account has administrative privileges, but Vista and upwards it's a LUA - the infections you get there are usually from stupids clicking "yeah sure, rape me anally" on the UAC prompts, not by malware doing sneaky privilege escalation.
A girl even helped create it :)
A transsexual guy, to be precise.
A rootkit wouldn't need to do the same level of virtualization that a full-blown hypervisor does - access to devices could be let through directly, filtering of disk access to hide the rootkit is done by intercepting OS drivers anyway. Running the rootkit as a hypervisor would still allow the rootkit to hide the memory it's operating in from the OS, as well as not allowing the OS full ring0 access.
I'm pretty sure this wouldn't give a noticeable speed hit for regular users, and would still be pretty darn effective.
More than half of OpenBSDs security is that security conscious people select that operating system.
Spot on the sugar.
Not if the rootkit intercepts MBR access.
The windows kernel put a user modifiable, and kernel-used data structure in place
Citation needed.
brain damaged VMS inspired model
Are you saying VMS is brain damaged, or that the way NT borrows VMS concepts is brain damaged? What exactly do you find brain damaged about the model?
A user-mode-only process can't do effective rootkitting, though, so it will be easy to detect and remove.
...and sudo probably isn't even going to be necessary, there's surely a fair amount of local privilege escalation bugs that haven't been detected yet. Yep, they'll get patched eventually, but a "Joe Clueless" won't be updating his system and thus won't get the fixes :)
Making the MBR invisible to the OS isn't BS, once the rootkit has loaded it will intercept disk access and return filtered data.
Won't be able to do that with a (clean) boot-from-cd/usb OS or tool of course, but that's a different story.
Boot the machine from a livecd, and don't have it connected to the network. If you're afraid of physical damage, use some old piece of junk; never seen an IT department that didn't have old junk lying around.
Oh yes, and there might even be plastic explosives in there!
Seriously, how often is something like that going to happen? Compared to how often people lose their sticks while shuffling for car keys...
Nope, doesn't exist! At least not on my shiny, lovable mac! ... ;)
For destruction? Your IT department is so technically challenged they can't figure out how to access a USB stick without risk of running malware from it? O_o
How many native developers will be working on browser teams, though?
While I don't personally believe everything will move to web apps, a lot is. Some of it for good reason, some of it because CEOs and other stupids thinks it's a good idea... so it's happening.
But hasn't it always been like that in IT? If you cling on to one old platform and aren't willing to learn new technologies, you're eventually going to become irrelevant?
I fail to see the difference between this and using some client-side application, other than the fact that WebGL is a cross-platform spec.
Drive-by exploits.
And in order to compromise the operating system with Flash or HTML5 Canvas, you have to find a buggy 2D driver. All I get out of this article is that 2D drivers are more mature than 3D drivers.
Indeed.
The 2D APIs are less complex, they have a smaller attack surface, and you don't get direct access to the OS's 2D API from the browser (thinly wrapped access to Windows GDI would be almost as bad an idea as thinly wrapped access to OpenGL).
Of course it's not native code, and of course the high-level API doesn't offer DMA access. Just like JavaScript, Java, Flash, Adobe Reader (et cetera) doesn't come with ExploitBufferOverflow() or LocalPrivilegeEscalation() functions... catch my drift? :)
WebGL is a more complicated API than, say, the 2d context for the html5 canvas, and it's one big step closer to a graphics API that was written exclusive with speed in mind.
Nice try :)
However, there's quite some differences between the APIs used by normal browser rendering, the 2d canvas context, and finally the WebGL canvas context. If you have followed Mozilla's work on GPU-accelerating Firefox, you should know that even "controlled" usage of the 3D APIs can be troublesome... and with WebGL, you pretty much remove the "control" part.
If WebGL is successful it will help to break the domination of DirectX among the desktop graphics hardware vendors and cause developers to look beyond the Microsoft romper room.
Ah yes, WebGL + JavaScript will displace native C++ code combine with OpenGL/DirectX? (That'd be a wet dream of Intel and AMD - even with JS JIT advances, we'd need quite more powerful CPUs).
It will require a couple of incidents before Google, Mozilla, et al. concede this and lock down WebGL, taking it off the table as a viable attack vector. Eventually they will. Bank on it.
Google are cool, but they aren't superhumans. Some things just aren't 100% securable.
Yes, it is a security problem. So why is this OK: https://www.microsoft.com/silverlight/future/#graphics (specificially: "Immediate mode graphics API allows direct rendering to the GPU").
It isn't a security vulnerability when Silverlight gains access to the GPU. Hhmmm.
It says "immedate mode graphics", it doesn't say "thin wrapper around DirectX" or "you can run shader code directly".
It's very possible it might in fact be a thing wrapper around DX, in which case I'd be the first to cry bloody murder... but you can't deduce much from just that statement.
It's not really about video memory, it's about shader code and driver bugs - which can (potentially) do a lot more damage than just reading video memory.