Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Other side of the airtight hatchway (Score 2) 150

MSDN is saying, by default, "Safe DLL" loading is used, in which the current directory is only used if loading the DLL from most other locations failed. So this would not be viable any more. It sounds like this problem was identified and fixed long ago. Any attempt to exploit this now would require gaining greater access first, and once you're there there's no point to using DLL hijacking any more.

Comment Re:Why is this a flaw in the app, and not the OS? (Score 5, Informative) 150

MSDN documents guidelines for preventing malicious DLL loading. Windows has already cut off "current directory" forms of attacks by changing the DLL load order (called "Safe DLL Search Mode" in that document), and with Vista locking down Program Files for admin-only access, "application directory" attacks are also out unless apps intentionally install themselves elsewhere (then they're on their own). As for installers, users have to get tricked into downloading the DLL first, and at least Chrome gives you a big warning that the file is suspicious due to its extension. And if you can get the user to do that, you might as well just give them an EXE and skip the warning. It's easier to put together a malicious EXE too.

Comment Inevitable (Score 1) 165

This isn't surprising if you've been following Chrome. By some metrics it's the most used browser now, and they dropped support for NPAPI plugins (like Java) due to security concerns. Oracle's official reply to this has been "use Firefox" which in my opinion was incredibly short sighted, unless they feel Java just won't work using PPAPI. Who on earth is going to use a plugin in their website that doesn't support one of the biggest browsers? That person would have to build a fallback for Chrome, and at that point they might as well just ditch Java and use the fallback for all browsers if it's good enough.

Comment Re:Simple explanation (Score 1) 165

All modern OSs will initialize the memory because there is a clear security issue with allowing one application access to the old contents of a random block of memory. It could contain passwords or who knows what else.

On the other hand, GPU memory is primarily used for rendering graphics. The security implications are less severe if information leaks. Has there ever been any guarantee information won't leak? So why do users assume that it won't? It is likely NOT cleared for speed reasons. Everyone wants a fast GPU cheap. Well, that's one way to get speed boost on allocation operations I'm sure.

It really should be Chrome's responsibility to zero out their GPU memory when they're done with it, to prevent information leakage. That's what incognito mode does with regards to history, cache, and cookies, so why not GPU memory?

Comment Re:AMD Open Source Driver on Linux (Score 4, Insightful) 148

Yeah. Your GPU was not designed with security of the information stored in it in mind. It was designed to play video games and a few other things, and it's not a big deal if a few of your game textures leak, if it means the GPU can be slightly faster at managing its memory. The responsibility should be Chrome's to clear out its GPU memory in incognito mode after it's done using it.

Comment Asimov has the right idea. (Score 1) 748

  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm. (Ensure accidents do not occur even if the car has to violate laws to do it.)
  2. A robot must obey orders given it by human beings except where such orders would conflict with the First Law. (Otherwise, obey all traffic laws.)
  3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law. (Back up the user's self-driving preferences to the cloud! OK maybe this one doesn't fit as well as the other two.)

Slashdot Top Deals

The star of riches is shining upon you.