I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): 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.

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.

> I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): 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.

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).

And for an attacker to exploit this (which in all likelihood is impossible anyways), they'd need to already be executing arbitrary code.

0xBuLL of 0xa bytes, dev's feelings come through loud and clear here.

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.

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/bdfd2017fb776b52a4604928e...

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.

Dang it, I counted the \0 but miscounted the characters in the string.