Slashdot Mirror


Duqu Installer Exploits Windows Kernel Zero Day

Trailrunner7 writes with an excerpt from Threatpost: "A newly discovered installer for the Duqu malware includes an exploit for a previously unknown vulnerability in the Windows kernel that allows remote code execution. Microsoft is working on a fix for the kernel vulnerability right now. The exact location and nature of the flaw isn't clear right now. The installer uses a Word document to exploit the vulnerability and then install the Duqu binaries."

6 of 164 comments (clear)

  1. Re:Word document for a remote exploit? by The+MAZZTer · · Score: 4, Informative

    It doesn't say remote vulnerability, it says remote code execution. It's probably a Word bug that allows execution of shellcode, which in turn exploits the LOCAL vulnerability in the Windows kernel for privilege elevation. "Remote" just refers to Duqu running code given to it over the network, I assume.

  2. Re:And? by X0563511 · · Score: 3, Informative

    You understand what a zero-day is right? Scanning the attachment would have done exactly nothing useful, and have given you a false sense of security on top of it!

    --
    For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
  3. Article is FUD. Requires user running as root. by Anonymous Coward · · Score: 0, Informative

    "Duqu consists of a driver file, a DLL (that contains many embedded files), and a
    configuration file. These files must be installed by another executable—the installer. The installer registers the
    driver file as a service so it starts at system initialization. The driver then injects the main DLL into services.exe.
    From here, the main DLL begins extracting other components and these components are injected into other pro-
    cesses. This process injection hides Duqu’s activities and may allow certain behaviors to bypass some security
    products."

  4. Re:There is already a fix out: by SadButTrue · · Score: 4, Informative

    wipe your disk and reinstall anything but Windows.

    FTFY

    --
    grape - the GNU free, open source rape
  5. Re:HOW the HELL by Dr_Barnowl · · Score: 5, Informative

    Everything, eventually, calls kernel APIs, or it wouldn't be able to DO anything. The kernel is the only way you're going to access the file system, the hardware, etc. It would be a pretty sorry-assed word processor that couldn't save files.

    The selection of Word as an attack vector was probably influenced by a combination of...

    • Word is probably the number 1 application that most professionals open after the browser.
    • Word has the extra advantage that it's not received as much hardening as the browser.
    • Office may use some of the reputed secret API calls that MS use to give it an advantage... these may be less hardened than public ones, or just less commonly exploited, thus they are a softer target.
    • The document data structure handling code in Word is likely a total mess, as revealed in the MOO-XML specs, because it contains support for a lot of very old versions of Word, and is probably more vulnerable to exploits than other parts of Office.
  6. Re:HOW the HELL by BitZtream · · Score: 2, Informative

    You simply do not have any idea how software works, which is ironic considering you're calling them stupid. Please realize that ALL IO, be it console, gui or file goes through the kernel right?

    Your super leet little Linux box works the same way.

    All apps access the kernel API in order to function. Just starting a process is an API call. To actually do anything useful on a computer, you're talking to the kernel, its what arbitrates between all of your apps. Yes, you may have a window manager doing the lifting, but in the end, the video drivers are in the kernel space, and to make any changes to the display, you gotta talk to the kernel.

    The kernel delivers your keystrokes to the application.

    The kernel plays sound that the application asks it too.

    The kernel displays whats on your monitor.

    The kernel is the only things that talks to ANY hardware on your machine directly, everything else in useland talks to it via the kernel.

    All most all 'kernel exploits' are done via user land code. There are extremely rare exceptions like exploiting kernel netcode and such like the old winnuke, teardrop and all those did. Those directly exploit bugs in the kernel because the kernel is the first thing that handles all network activity in and out of the machine. Otherwise, your two options for exploiting the kernel are userland applications and kernel loadable modules. Well, if you can load a klm, you own the machine anyway, thats a feature, not an exploit.

    So basically the only way any exploit happens (or the vast majority of them really) is by using a userland application to make a kernel API call that can be exploited due to a bug. The kernels job is to play police officer and make sure nothing like this happens, but, its not perfect, regardless of what OS you're running, and those bugs get found, someone crafts an exploit and figures out a good vector for delivery. That may be through a network connection via Apache or IIS (these are both userland applications) or in this case, I get you to open a word doc that materializes the exploit. It doesn't even have to be a word problem, could be an image with bad data that gets loaded by the default libraries and something weird happens there, Word is just a way to start the process.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager