4 ms·

Tweet has been deleted: https://twitter.com/i0n1c/status/738258436161449984 https://twitter.com/i0n1c/status/738258436161449984 I deleted the tweet with the pi

• personjerry 10y ago
  I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): http://stackoverflow.com/a/14333217/3650441 http://stackoverflow.com/a/14333217/3650441 If an attacker knows what files Blizzard is calling access() on, they could likely use this exploit and execute arbitrary code.
  • valleyer 10y ago
    The existence of the inherent time-of-check versus time-of-use hole with access is a several steps away from "execute arbitrary code". The example given presumes you are using access on crontab (and that the app can write to it).
  • yoz-y 10y ago
    Could they though? The way I understand the answer is that the security hole happens if a privileged user which manipulates files for an unprivileged user calls access() and then open(). In this case Blizzard's application is an unprivileged user, thus even if you manage to insert yourself between the calls, you will only be able to make Blizzards application execute code. The application still runs in a sandbox so you will not get that far.
  • ryanlol 10y ago
    And for an attacker to exploit this (which in all likelihood is impossible anyways), they'd need to already be executing arbitrary code.
  • cyphar 10y ago
    > I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): http://stackoverflow.com/a/14333217/3650441 http://stackoverflow.com/a/14333217/3650441 That is not a security flaw in access, it's a potential security flaw in administrative processes that use access() and then operate on files. There's a hole there where someone could swap the file that they are trying to open. That's just a reason to not use that API (there are the at APIs for a reason). But since Blizzard processes are (presumably) not running as root, there isn't a security flaw. > If an attacker knows what files Blizzard is calling access() on, they could likely use this exploit and execute arbitrary code. The ability to maybe* get a program to do some file operations on a different file than it checked against is miles away from code execution, unless the program's job is to execute code from a file.
• mzs 10y ago
  0xBuLL of 0xa bytes, dev's feelings come through loud and clear here.
  • JoachimSchipper 10y ago
    You're looking at the output of a disassembler, not at the original source code. It probably reads something boring like sizeof(Identifier) in the original.
    • LeifCarrotson 10y ago
      That's exactly what it is. The third parameter to memcmp is the length of the buffers to be compared - "G847MC6JZ5", the string being compared, has a length of 11 characters (including the null terminator, which is a little odd). 11 is B in hex, and is stored as an unsigned Long Long, so the representation in the disassembler is 0xBuLL. And that string is the Blizzard identifier: https://www.virustotal.com/en/file/bdfd2017fb776b52a4604928e74bca9ca0d5bbe7b9d93782f94b0348e9f430bd/analysis/ https://www.virustotal.com/en/file/bdfd2017fb776b52a4604928e...
      • tomlogic 10y ago
        Not odd to include the null terminator if you want to ensure another string is "equal to", not just "starts with" the string you're comparing it to.
        • mzs 10y ago
          Dang it, I counted the \0 but miscounted the characters in the string.