Hacker News Reader

Comment by kgeist | Hacker News Reader

>This vulnerability affects users working on multi-user machines where a malicious actor could create a .git directory in a shared location above a victim’s current working directory

If a malicious actor has access to the filesystem, isn't it a bigger problem? I remember Raymond Chen recounted in his blog that Microsoft usually dismisses vulnerability reports that start with "to use the exploit, you must have access to the machine". As he likes to say, "the gates are already open". If you already have access to the machine and can create files outside of your home directory, what stops you from causing even greater havoc?

View on HN

In the case of a multi-user machine, e.g. in a library, you expect there to be low privilege users with filesystem access. This bug introduces a way for them to do privilege escalation and potentially run code as root, which you did not intend.

Generally, you still want these additional protections even if you don't expect others to have access to a machine. Can't say if one or the other is a bigger problem. I think they are all components of having a secure system.

I mean, we have multiple user accounts for a reason. Maybe less so on windows but on unix with its mainframe ancestory, local priv escalation definitely feels like a real bug (then again, on linux it would be super weird for / to be writeable by someone not root)

> If you already have access to the machine and can create files outside of your home directory, what stops you from causing even greater havoc?

These systems don't let you put files in other people's directories. You can only create things in a specific spot, and if that thing is a directory then you and only you can put files inside it. Sometimes the only thing you can make in that spot is a directory.

(Other users can access those files if you explicitly add them to the permissions, of course.)

Network shares on corporate networks come to mind, they don’t need to be git repositories either (and presumably chowning all files to 1000:1000 would hit the large majority of Linux users even with this fix)

Reply on news.ycombinator.com