3 ms·

I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): http://stackoverflow.com/a/14333217/3650441 http://stack

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.

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.