3 ms·

>Of course it does: it means any malware that manages to get onto the machine running as a non-administrator can arbitrarily compromise Chrome. No. The malware

>Of course it does: it means any malware that manages to get onto the machine running as a non-administrator can arbitrarily compromise Chrome. No. The malware would need to be run under an account with write access to Chrome. Because Chrome is in a user directory, the only accounts that should have write access to it are administrator, and that same user. If malware is running as the normal user account, then it can compromise the Chrome executable, and be able to run on that same user account when Chrome gets re-run. However, this at best allows malware to turn a 1 time compromise into a persistent compromise, and even then it is an ability that the malware has anyway. Assuming that Windows has no mechanism for a user to execute arbitrary code at login (which I doubt), the malware can always replace one of the shortcuts on the desktop with a shortcut to a malicious executable, that then loads the original executable, and maintains the same icon. Granted it is harder to detect a compromised executable, but if you do not know to look, how often to you check shortcuts/login programs? The malware cannot use this for privledge escalation because the only user who should ever run the Chrome executable is the user in whom's directory the executable is installed. And this is also the only non-administrator who could have compromised it in the first place. Installing to a user directory does however prevent another type of privledge escalation, because you do not ever need the give the executable (or installer) administrative access. EDIT: I completely re-wrote this while Silhouette wrote a responce.

Silhouette 14y ago
If an executable is installed where it can not be simply overwritten, then compromising a session is not sufficient to permanently compromise the program. If it is in the user's directory, then compromising one session lets malware insert it self and compromise every session. Exactly. There's an old notion in computer security that as long as you can stop someone getting root, you're doing fairly well. In an age where data leakage, privacy invasion and phishing are probably more serious threats than causing "real damage" that can be fixed by simply (relatively speaking) reinstalling and/or restoring from back-ups, I find the emphasis on not being admin by default rather quaint. Of course it's a step in the right direction, but it's nowhere near sufficient. Any user probably has access to their own e-mail, files, and so on. Often, that data will be far more valuable to an attacker or disclosing it will be far more costly to the victim than merely installing a virus that makes old-school letters drop down the screen or even than turning the machine into part of a botnet. Ideally, we'd have an OS-level access control model that restricted access by application and data type, not just by user. There are practical challenges to implementing such a model without unacceptably compromising usability, but at least ensuring that only the intended applications are running is a significant step in the right direction. By avoiding that level of explicit check on changing code you're going to run, Chrome is stepping in the opposite and exactly wrong direction.
- gizmo686 14y ago
  As I pointed out in my re-write of my original responce, even if Chrome was installed in Program Files, compromising it would still give malware a persistent compromise on the user. With regards to your OS-level access control, I think we have examples of how to do it without usability problems. For example, in smartphones, when apps get installed they define what permissions they need. If we assume the publisher of an app is not malicous, then their is no need for a typical user to need to know about this, and we can view it as the app saying "these are the things I am going to access, if I try to access anything else, then I have probably been compromised". The smartphone implementation seems a bit to crude to be very effective in stopping malware, however there is no reason why we should not be able to make a more fine grained system. For example, in the Linux world, we have apparmor, which does effectively the same, but is much more configurable. Still, this only requires the program to be honest at install time, and to not have write access to the apparmor configuration file; the user does not need to be aware of its existence. The problem with these systems is that programs need to do things that we do not want malware to be able to do. For example, Chrome has an auto-update feature. If it gets compromised, then the malware can overwrite the executable just as easily (unless the OS enforces code signing). Say that the program wants to be able to create shortcuts on the desktop, and save data to the harddrive. Now, if it gets compromised, the malware can save itself to the harddrive, and create a shortcut on the desktop labeled "Chrome.exe".

Silhouette 14y ago

If an executable is installed where it can not be simply overwritten, then compromising a session is not sufficient to permanently compromise the program. If it is in the user's directory, then compromising one session lets malware insert it self and compromise every session. Exactly. There's an old notion in computer security that as long as you can stop someone getting root, you're doing fairly well. In an age where data leakage, privacy invasion and phishing are probably more serious threats than causing "real damage" that can be fixed by simply (relatively speaking) reinstalling and/or restoring from back-ups, I find the emphasis on not being admin by default rather quaint. Of course it's a step in the right direction, but it's nowhere near sufficient. Any user probably has access to their own e-mail, files, and so on. Often, that data will be far more valuable to an attacker or disclosing it will be far more costly to the victim than merely installing a virus that makes old-school letters drop down the screen or even than turning the machine into part of a botnet. Ideally, we'd have an OS-level access control model that restricted access by application and data type, not just by user. There are practical challenges to implementing such a model without unacceptably compromising usability, but at least ensuring that only the intended applications are running is a significant step in the right direction. By avoiding that level of explicit check on changing code you're going to run, Chrome is stepping in the opposite and exactly wrong direction.

gizmo686 14y ago
As I pointed out in my re-write of my original responce, even if Chrome was installed in Program Files, compromising it would still give malware a persistent compromise on the user. With regards to your OS-level access control, I think we have examples of how to do it without usability problems. For example, in smartphones, when apps get installed they define what permissions they need. If we assume the publisher of an app is not malicous, then their is no need for a typical user to need to know about this, and we can view it as the app saying "these are the things I am going to access, if I try to access anything else, then I have probably been compromised". The smartphone implementation seems a bit to crude to be very effective in stopping malware, however there is no reason why we should not be able to make a more fine grained system. For example, in the Linux world, we have apparmor, which does effectively the same, but is much more configurable. Still, this only requires the program to be honest at install time, and to not have write access to the apparmor configuration file; the user does not need to be aware of its existence. The problem with these systems is that programs need to do things that we do not want malware to be able to do. For example, Chrome has an auto-update feature. If it gets compromised, then the malware can overwrite the executable just as easily (unless the OS enforces code signing). Say that the program wants to be able to create shortcuts on the desktop, and save data to the harddrive. Now, if it gets compromised, the malware can save itself to the harddrive, and create a shortcut on the desktop labeled "Chrome.exe".