Sign in / up

back to article Windows Atom Tables popped by security researchers

Wonderful: a security researcher has found a way to abuse the system-level Atom Tables in Windows – all versions of Windows, through to Win 10. Atom Tables are defined by the system to store strings with an identifier to access them; they can be global (like the tables that pass data via DDE between applications), or local ( …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. sabroni Silver badge

    Super cool name!

    But looking into it it seems they're saying they can store executable code (though limited to 255 bytes in length according to the MS docs) as a string in an atom table. They probably should be able to do this, shouldn't they? How could the atom table code tell if the bytes make up a string or an executable?

    The issue seems to be that applications can read those strings and then be tricked into executing them. That's applications that trust their input too much. The idea that the atom tables are at fault because they're the source of that input seems a bit weird.

    When you go to retrieve a string that someone else wrote you should validate it. You certainly shouldn't execute it. Wherever it comes from.

    10 0 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Super cool name!

      If I remember correctly, this was a Microsoft Windows 3.1 feature… Wikipedia reckons it's a 2.0 feature released in 1987, making the vulnerability nearly as old as I am.

      That was certainly the era of "She'll be right, mate" style validation and sanitation of inputs.

      2 1 Reply
    2. AndyS
      Reply Icon

      Re: Super cool name!

      I agree. I reckon this is the same level of vulnerability as a keyboard which can, after all, be used to input malicious code as strings.

      What if the string I want to discuss is something like Robert'); DROP TABLE Students; -- ? There is nothing inherently wrong with storing that string, as I assume the Reg is about to competently demonstrate when I press the Submit button.

      7 0 Reply
      1. Sampler
        Reply Icon

        Robert'); DROP TABLE Students; -- ?

        Ah yes, AndyS, little Bobby Tables...

        https://xkcd.com/327/

        2 1 Reply
      2. kryptylomese
        Reply Icon

        Re: Super cool name!

        Atom tables seem like a meritorious design on the face of it, but this is more like someone else having a keyboard that can type things into your memory.

        Application programmers can be considered to be naive to have trusted atom tables in the first place. However, please remember that Windows was not designed with security as a primary objective.

        2 0 Reply
    3. Lee D Silver badge
      Reply Icon

      Re: Super cool name!

      They are just a data store, yes.

      But if nobody has considered that an Atom Table can be modified by other malicious programs, likely they aren't sanitising the input. And given their length of history, there are bound to be thousands of apps that can be crashed in particular ways with a dodgy Atom Table entry that they try to use.

      I would hazard that there's at least one in an office suite somewhere.

      This is why I don't like inter-process things, stores, registries, services, internal kernel buses and all the other stuff. There' are too many entry points to send data to programs that are not visible to users or even the programmer, and that means they are too hard to sanitise and isolate properly.

      But you don't need to execute the code directly. If you do it right, that Atom Table entry might be copied into RAM, contain a buffer size, which the program acts upon, and then if you corrupt it it might be able to fall off the end into a copy of whatever string you've stored in the Atom Table, which might well mean that executable code sitting at the end of it ends up getting executed. It's not that people "run" the Atom Table. It's that it can be used as a source of potential buffer overflows and the code that they will overflow into.

      2 0 Reply
      1. Brewster's Angle Grinder Silver badge
        Reply Icon

        Re: Super cool name!

        "But if nobody has considered that an Atom Table can be modified by other malicious programs, likely they aren't sanitising the input. And given their length of history, there are bound to be thousands of apps that can be crashed in particular ways with a dodgy Atom Table entry that they try to use."

        Windows machines were single user machines so if an app was running it was probably authorised by the user and to be trusted. And, anyway, if you could manipulate the atom table you could simulate key presses and mouses click and find umpteen other vectors far easier to exploit that putting shell code in a string and attempting a buffer overflow. Sanitisation was done to protect against corrupted files, stupidity (a user coming along and tweaking your registry keys) or a bug in another program. It wasn't done to protect against malicious programs.

        0 1 Reply
        1. a_yank_lurker
          Reply Icon

          Re: Super cool name!

          @Brewster's Angle Grinder - Originally all PCs were standalone, single user devices. Later local networks modified this somewhat but the network was isolated from the world. In both cases, the introduction of malware required physical access and disk to the machine/network. Windows is derived from DOS which was a fairly typical PC OS of the era. None of these OSes were designed for a large scale interactive system or the Internet. Thus, any of the PC OSes are likely to have some nasty attack vectors that could be impossible to properly patch. But since Windows is the only major PC OS still available it is likely to show these types of bugs.

          Unix was designed for a large scale network from the beginning and current versions and derivatives have kept this design legacy. This means that the original design made some consideration for isolating users from administrators and limiting user capabilities. The assumption was not necessarily malicious users but incompetent users, if they had proper permissions, could take down the system with very serious consequences.

          2 0 Reply
  2. Anonymous Coward
    Anonymous Coward

    Wow... Atom tables reach all the way back to Windows v1.0 when the world was a much simpler place. I guess the code never got changed.

    0 1 Reply
    1. Charles 9
      Reply Icon

      Because it was never broken. And you know what they say about what to do if it isn't broken...

      And the thing is that this can be the initial link of an execution chain. Imagine linking this to a privilege escalation...

      1 0 Reply
  3. JeffyPoooh
    Pint

    I read the headline as "Windows Atom Tablets popped..."

    My refurbished Gigabyte T1000 Windows 7 Atom CPU Laptop/Tablet arrived just yesterday. Only C$105 (=US$78) shipped.

    Ah, Tables not Tablets.

    Phew. I'm glad that my 'new' gadget is no more popped than anything else...

    4 2 Reply
  4. David Roberts

    Firewalls to block the downloading of executables?

    At first glance this looks like a "magic fairy dust" solution for where there is no easy fix.

    Presumably the answer to all attacks - as long as the firewall can:

    (1) Identify all potential executables including interpreted scripts.

    (2) Not block anything covered by (1) that you really do want to download.

    I would be interested to know if this is a realistic proposal.

    0 0 Reply
    1. nagyeger
      Reply Icon

      Re: Firewalls to block the downloading of executables?

      And... how far down the chain does this go? Are "atom tables" aceesible in Silverlight, flash, macros in word docs, javascript?

      0 0 Reply
    2. Charles 9
      Reply Icon

      Re: Firewalls to block the downloading of executables?

      "Identify all potential executables including interpreted scripts."

      Wouldn't that just be a matter of fencing in the interpreter so that IT can't do anything bad?

      0 0 Reply
    3. a_yank_lurker
      Reply Icon

      Re: Firewalls to block the downloading of executables?

      @David Roberts - The short answer - No. Users will need to run new executables from time to time and it is fairly easy to hide executables in other code (Office macros for example). Users and admins will have a hard time with setting up the rules correctly at the local firewall level.

      1 0 Reply
  5. Ken Hagan Gold badge

    Two fairly whopping mitigating factors:

    1) No windows APIs actually execute the strings that are atomised in these tables and converting an atom back into a string is a relatively rare operation. (By far the more common use case is converting the string you are interested in to an atom and then seeing if it matches the atom you've been offered. In fact, probably the only programs that convert the other way are debug utilities.) Therefore, it is vanishingly unlikely that the string you've inserted will ever exist in the address space of the process you are trying to attack.

    2) Unless you have elevated processes running in your window station, there is nothing you can attack that doesn't have exactly the same access as the attacker. So you can only attack processes that you can already control by all sorts of existing means (such as TerminateProcess or CreateRemoteThread) and so it isn't really a security vulnerability.

    So unless further details are forthcoming, I have to assume that this is just someone trying to drum up some publicity for themselves.

    1 1 Reply
    1. Anonymous Coward
      Reply Icon
      Facepalm

      re: Two fairly whopping mitigating factors:

      "if I could add a buffer containing shellcode to the global atom table by calling GlobalAddAtom, and then somehow get the target process to call GlobalGetAtomName I could copy code from my process to the target process, without calling WriteProcessMemory" ref

      0 0 Reply
    2. patrickstar
      Reply Icon

      After actually reading http://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/ , this isn't a vulnerability per se and doesn't really allow privilege escalation*.

      It's a way to inject code into processes (a la WriteProcessMemory/CreateRemoteThread/etc) without getting detected by anti-malware software.

      It does however remind me of a classic NT 4 kernel vulnerability in the NtAddAtom function!

      http://insecure.org/sploits/NT.get-admin.kernal.hole.html

      * Well, indirectly you could use it to gain more privileges or access to more hosts, as you can use it to hijack a remote desktop session or log terminal sessions, for example. But that's when you have code running as the same user as that process already.

      0 0 Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon