33 ms·

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by def

by walki 3y ago

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few days ago where he asked if there was a Windows setting for disallowing any access to %Appdata%. The response was that if access to %Appdata% is completely blocked Windows won't work anymore.

mrguyorama 3y ago
>python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Yes, otherwise known as "if you run code on your computer, it can run code on your computer". If a random python program can "decrypt" the passwords, that's not encryption. And browser password management isn't about security, but convenience.
- lukevp 3y ago
  Full unrestricted disk access for all users and code isn’t the only way an OS can be designed.
  - mrguyorama 3y ago
    AppData is specifically where apps store data, and there are and were plenty of legitimate examples where you want some code to access data from an app in there. The entire point is that it is not meant to be a secure location, was never meant to be a secure location, has no intended security features etc. If you store your passwords in a text file on the desktop, that is also insecure but you would be wrong to say Notepad has a security vulnerability. Similarly, if you stored your passwords in the Windows registry unencrypted, that would also be insecure, but does not demonstrate a flaw in the Windows registry. If you want to be able to leave your secrets in the open without them being compromised, then you encrypt them. Browser password managers are not secure. That is not Window's fault.
    - MiguelX413 3y ago
      Regardless, full unrestricted disk access for all users and code is insecure.
      - mrguyorama 3y ago
        It isn't full unrestricted disk access for all users and all code. Any OTHER user, or code running with that user's permissions cannot access YOUR appdata directory. The appdata stuff was the running user's appdata. They already had total control of the user's machine, and in fact, had control of that user's domain administrator! This attack is only possible if you have control of the user's domain administrator AND data access to the user's machine so that you can use both the locally stored Bitwarden data AND the domain's backup decryption keys. The phone OS model wouldn't work here. The security compromise happened when the domain administrator account was breached.
- baldfat 3y ago
  I tell myself and other people if you have it saved in your browser are you okay if bad people know that password. Also it makes it easy for people in authority to get to that password with a simple court order.
  - mrguyorama 3y ago
    Most average people are not sure of password managers because the idea of losing the god password and losing access to EVERYTHING is terrifying, and there is mathematically no way to recover your secrets. Most normal people have lost a password before, so that's something they think about. Also for most normal people, an unencrypted note on their desktop with plaintext passwords that are DIFFERENT FOR EVERY SITE is STILL more secure than the SOP of using one strong password for everything. For that to be compromised, someone needs to be able to run code on my local machine, in which case, they can just install a keylogger, so encrypted passwords are no increase in security. I genuinely don't care if App1 on my computer can fiddle with App2's bits, because I chose to run App1 and App2, they are trusted.
  - lxgr 3y ago
    Passwords saved in browsers for most users only protect access to accounts that are also accessible with a simple court order, though.
- AlienRobot 3y ago
  >if you run code on your computer, it can run code on your computer For the love of God will someone please just make a web browser that isn't a web browser and it's just a cross platform multimedia sandbox with a couple of APIs in it, and you can run programs written in rust or something on it, and it doesn't let the programs touch your file system unless it has explicit permission? That would solve 99% of the application use cases. That's literally everything I want. I want the safety of the browser, outside the hell that is web development.
  - mrguyorama 3y ago
    It's called iOS. Browsers are also NOT safe. You know what was safe? Not letting random endpoints ship you code to run. HTML was safe, though implementations at the time likely had security flaws. You cannot make a turing complete language that JIT compiles into machine code and verify it as "safe". Machine code is not safe, so anything that lets you generate arbitrary machine code cannot be proven to be safe. If you take away the arbitrary machine code generation from javascript, it's too slow to run the modern web.
    - semolino 3y ago
      On a related note, I appreciate the ability to specifically disable JavaScript JIT in GrapheneOS' browser, Vanadium. Theoretically, it's a nice balance of maintaining site compatibility (as opposed to disabling JS entirely) and reducing one's attack surface.
    - withinboredom 3y ago
      I still can't use a password manager to keep my apple account secure. You must memorize your password, and be able to type ... uh, I mean, draw, no, write? your password on a watch as well (if you get one of those). iOS is not exactly safe until I can use it without knowing my apple password.
      - fragmede 3y ago
        I don't know my Apple password, it's in 1password. I don't use it on my watch though, I have a PIN there.
giancarlostoro 3y ago
> The response was that if access to %Appdata% is completely blocked Windows won't work anymore. Yikes. I really wish that instead of Microsoft wasting resources on telemetry nonsense, they would focus on optimizing their OS and modernizing some of these blatant security issues. I guess it wont happen until we have another wave of ransomware malware or something of the sort.
- iudqnolq 3y ago
  That's like saying Linux doesn't have sandboxed apps because chmod -R 000 /var will break your system. Technically sort of right, but not a useful or interesting observation.
  - giancarlostoro 3y ago
    The difference being Windows is a much higher target for abuse since its the most commonly used OS for Desktop, somewhere as high as 70% marketshare or higher, depending on where you get those numbers from. It's also used a lot in corporate environments as well. Linux usage of /var/ and /etc/ differs depending on various factors too... Developers / distro maintainers put files in different places.
zelon88 3y ago
"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or ignorant programmers who don't take any pride in their work, or lack all respect for the users environment. For example; an .ini file should not be a thing in Windows. That is what the registry is for. But the programmer writes the code for Linux, half-ass ports it to Windows, and leaves the .ini file because his code is more important to him than the end-users operating system. There is nothing wrong with AppData permissions. The problem is with the users understanding of what it is for, and the developers understanding of how it should be used.
- burnte 3y ago
  Thank you! And Program Files is for x64 windows apps, Program Files x86 is for 32bit apps but vendors use both interchangeably and sometimes use both for the same app!
  - rkagerer 3y ago
    Don't forget about Wow64 and redirection ;-).
- EvanAnderson 3y ago
  As a Windows sysadmin AppData has been an unmitigated shit show forever. Developers (including those inside Microsoft) don't give a damn about how Microsoft intends anything to work, and AppData has become a dumping ground of software installs to end-run IT departments. A lot of malware dumps into there but good luck limiting execution from that directory hierarchy because all your business-critical end user communication apps live there now too. The functionality of roaming users profiles (i.e. registry settings "following" you to a different computer, which gives a really slick user experience when it works) was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for). In Windows 2000-land you could redirect AppData to a UNC path and mostly get around this behavior. That's not really "a thing" anymore because you've got apps like Microsoft Teams storing sizable databases in these locations and getting really, really cranky if network connectivity is interrupted. Windows development betrays its legacy DOS parentage even for devs who never lived thru that era. There were no rules. There was no adult supervision. There was poor documentation of APIs so you just hacked something together that worked well-enough. Periodically Microsoft tries to start over (all the APIs w/ "2" at the end, et. al.) and the cycle repeats.
AlienRobot 3y ago
There's probably nothing that I hate in programming more than having full access to the file system. Any time I write a program that has to delete a file I just make it move into a trash folder instead just in case I mess up somewhere and accidentally delete the entire file system.
- pi-e-sigma 3y ago
  Obligatory: https://youtu.be/buoNv4v_UKE https://youtu.be/buoNv4v_UKE
dist-epoch 3y ago
AppData is the Windows equivalent to Linux home directory dotfiles. > Ideally applications should only have access to their own directories This happens for Windows Store apps, which are sandboxed similarly to mobile phone apps.
bhdlr 3y ago
So - the moral of the story is to never use Windows?
- sjfjsjdjwvwvc 3y ago
  Or don’t use their „security“ features. AFAICT everything would have been fine if they used a hardware key as second factor.
  - lxgr 3y ago
    How do you know which app is accessing your hardware key in the absence of any OS feature mediating access to it?
adontz 3y ago
I believe the following is the solution. https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation https://learn.microsoft.com/en-us/windows/win32/secauthz/app... No?
- cameronh90 3y ago
  Essentially yeah but it’s currently opt-in from the app developer. I believe (but may be wrong) that an app which doesn’t implement AppContainer isolation can currently access the data written by apps that do implement it. I think the intention is for it to become the default one day.
shortsunblack 3y ago
Microsoft is trying to do that with msix and a new filesystem driver that transparently restricts file system access to app. Should land into Windows 11 this year. See https://youtu.be/8T6ClX-y2AE https://youtu.be/8T6ClX-y2AE for the functionality explaination.
- hervem 3y ago
  And AppStore distributed application which are by default isolated, removing some feature too. (custom shortcut for example).
- viraptor 3y ago
  The msix story is really weird/incomplete so far. Let me just leave it at: creating services is part of msix on windows 11, but not windows server. Maybe it will be more then a toy in a few years, but we'll still have to wait for old server versions to get replaced.
Pesthuf 3y ago
Is there even a way to opt in to having a secret be accessible only for your process? Like, a way to maybe sign your executable and then use a windows api that then gets "oh. This process is made by the same vendor that created this secret, so it’ll be allowed access". It’s just ridiculous that the most trivial, unprivileged process can just steal any file and any secret accessible by the user it’s run as. Unless that secret is protected with a key derived from a separate password the user has to put in.
- o11c 3y ago
  I don't think it's possible on Windows. It's trivial on Unix - just make the program setgid and change the folder permissions to only allow the group. This can be nested, though that requires that the relevant program be aware of the need to walk through several levels, though often a symlink can hide that. Note that when creating such a directory setup, `chown`ing away the user requires a privileged helper utility. But you need to make such utilities anyway so the user can delete such directories. *** Important note - most other "solutions" only protect you from apps the opt in to security. A proper solution, like this one, protects from all processes running as user, except the process of note.
  - viraptor 3y ago
    Or use selinux/apparmor - those have supported app sandboxing without group tricks for a long time.
    - o11c 3y ago
      Those are useless because they're opt-in, and we can't expect malicious programs to opt in. There's probably some mandatory mode but since it breaks all sorts of programs nobody can afford to use it.
      - viraptor 3y ago
        Apparmor is opt-in so it protects from exploration mostly, but selinux can definitely work with the whole system by default. It's not trivial, but you can at least prevent apps from accessing personal information unless explicitly allowed. I've been using it for years without issues. It really requires only a minimal amount of learning and you don't need to turn it off.

by walki 3y ago

mrguyorama 3y ago

>python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Yes, otherwise known as "if you run code on your computer, it can run code on your computer". If a random python program can "decrypt" the passwords, that's not encryption. And browser password management isn't about security, but convenience.

lukevp 3y ago
Full unrestricted disk access for all users and code isn’t the only way an OS can be designed.
- mrguyorama 3y ago
  AppData is specifically where apps store data, and there are and were plenty of legitimate examples where you want some code to access data from an app in there. The entire point is that it is not meant to be a secure location, was never meant to be a secure location, has no intended security features etc. If you store your passwords in a text file on the desktop, that is also insecure but you would be wrong to say Notepad has a security vulnerability. Similarly, if you stored your passwords in the Windows registry unencrypted, that would also be insecure, but does not demonstrate a flaw in the Windows registry. If you want to be able to leave your secrets in the open without them being compromised, then you encrypt them. Browser password managers are not secure. That is not Window's fault.
  - MiguelX413 3y ago
    Regardless, full unrestricted disk access for all users and code is insecure.
    - mrguyorama 3y ago
      It isn't full unrestricted disk access for all users and all code. Any OTHER user, or code running with that user's permissions cannot access YOUR appdata directory. The appdata stuff was the running user's appdata. They already had total control of the user's machine, and in fact, had control of that user's domain administrator! This attack is only possible if you have control of the user's domain administrator AND data access to the user's machine so that you can use both the locally stored Bitwarden data AND the domain's backup decryption keys. The phone OS model wouldn't work here. The security compromise happened when the domain administrator account was breached.
baldfat 3y ago
I tell myself and other people if you have it saved in your browser are you okay if bad people know that password. Also it makes it easy for people in authority to get to that password with a simple court order.
- mrguyorama 3y ago
  Most average people are not sure of password managers because the idea of losing the god password and losing access to EVERYTHING is terrifying, and there is mathematically no way to recover your secrets. Most normal people have lost a password before, so that's something they think about. Also for most normal people, an unencrypted note on their desktop with plaintext passwords that are DIFFERENT FOR EVERY SITE is STILL more secure than the SOP of using one strong password for everything. For that to be compromised, someone needs to be able to run code on my local machine, in which case, they can just install a keylogger, so encrypted passwords are no increase in security. I genuinely don't care if App1 on my computer can fiddle with App2's bits, because I chose to run App1 and App2, they are trusted.
- lxgr 3y ago
  Passwords saved in browsers for most users only protect access to accounts that are also accessible with a simple court order, though.
AlienRobot 3y ago
>if you run code on your computer, it can run code on your computer For the love of God will someone please just make a web browser that isn't a web browser and it's just a cross platform multimedia sandbox with a couple of APIs in it, and you can run programs written in rust or something on it, and it doesn't let the programs touch your file system unless it has explicit permission? That would solve 99% of the application use cases. That's literally everything I want. I want the safety of the browser, outside the hell that is web development.
- mrguyorama 3y ago
  It's called iOS. Browsers are also NOT safe. You know what was safe? Not letting random endpoints ship you code to run. HTML was safe, though implementations at the time likely had security flaws. You cannot make a turing complete language that JIT compiles into machine code and verify it as "safe". Machine code is not safe, so anything that lets you generate arbitrary machine code cannot be proven to be safe. If you take away the arbitrary machine code generation from javascript, it's too slow to run the modern web.
  - semolino 3y ago
    On a related note, I appreciate the ability to specifically disable JavaScript JIT in GrapheneOS' browser, Vanadium. Theoretically, it's a nice balance of maintaining site compatibility (as opposed to disabling JS entirely) and reducing one's attack surface.
  - withinboredom 3y ago
    I still can't use a password manager to keep my apple account secure. You must memorize your password, and be able to type ... uh, I mean, draw, no, write? your password on a watch as well (if you get one of those). iOS is not exactly safe until I can use it without knowing my apple password.
    - fragmede 3y ago
      I don't know my Apple password, it's in 1password. I don't use it on my watch though, I have a PIN there.

giancarlostoro 3y ago

> The response was that if access to %Appdata% is completely blocked Windows won't work anymore. Yikes. I really wish that instead of Microsoft wasting resources on telemetry nonsense, they would focus on optimizing their OS and modernizing some of these blatant security issues. I guess it wont happen until we have another wave of ransomware malware or something of the sort.

iudqnolq 3y ago
That's like saying Linux doesn't have sandboxed apps because chmod -R 000 /var will break your system. Technically sort of right, but not a useful or interesting observation.
- giancarlostoro 3y ago
  The difference being Windows is a much higher target for abuse since its the most commonly used OS for Desktop, somewhere as high as 70% marketshare or higher, depending on where you get those numbers from. It's also used a lot in corporate environments as well. Linux usage of /var/ and /etc/ differs depending on various factors too... Developers / distro maintainers put files in different places.

zelon88 3y ago

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or ignorant programmers who don't take any pride in their work, or lack all respect for the users environment. For example; an .ini file should not be a thing in Windows. That is what the registry is for. But the programmer writes the code for Linux, half-ass ports it to Windows, and leaves the .ini file because his code is more important to him than the end-users operating system. There is nothing wrong with AppData permissions. The problem is with the users understanding of what it is for, and the developers understanding of how it should be used.

burnte 3y ago
Thank you! And Program Files is for x64 windows apps, Program Files x86 is for 32bit apps but vendors use both interchangeably and sometimes use both for the same app!
- rkagerer 3y ago
  Don't forget about Wow64 and redirection ;-).
EvanAnderson 3y ago
As a Windows sysadmin AppData has been an unmitigated shit show forever. Developers (including those inside Microsoft) don't give a damn about how Microsoft intends anything to work, and AppData has become a dumping ground of software installs to end-run IT departments. A lot of malware dumps into there but good luck limiting execution from that directory hierarchy because all your business-critical end user communication apps live there now too. The functionality of roaming users profiles (i.e. registry settings "following" you to a different computer, which gives a really slick user experience when it works) was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for). In Windows 2000-land you could redirect AppData to a UNC path and mostly get around this behavior. That's not really "a thing" anymore because you've got apps like Microsoft Teams storing sizable databases in these locations and getting really, really cranky if network connectivity is interrupted. Windows development betrays its legacy DOS parentage even for devs who never lived thru that era. There were no rules. There was no adult supervision. There was poor documentation of APIs so you just hacked something together that worked well-enough. Periodically Microsoft tries to start over (all the APIs w/ "2" at the end, et. al.) and the cycle repeats.

AlienRobot 3y ago

There's probably nothing that I hate in programming more than having full access to the file system. Any time I write a program that has to delete a file I just make it move into a trash folder instead just in case I mess up somewhere and accidentally delete the entire file system.

pi-e-sigma 3y ago
Obligatory: https://youtu.be/buoNv4v_UKE https://youtu.be/buoNv4v_UKE

dist-epoch 3y ago

AppData is the Windows equivalent to Linux home directory dotfiles. > Ideally applications should only have access to their own directories This happens for Windows Store apps, which are sandboxed similarly to mobile phone apps.

bhdlr 3y ago

So - the moral of the story is to never use Windows?

sjfjsjdjwvwvc 3y ago
Or don’t use their „security“ features. AFAICT everything would have been fine if they used a hardware key as second factor.
- lxgr 3y ago
  How do you know which app is accessing your hardware key in the absence of any OS feature mediating access to it?

adontz 3y ago

I believe the following is the solution. https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation https://learn.microsoft.com/en-us/windows/win32/secauthz/app... No?

cameronh90 3y ago
Essentially yeah but it’s currently opt-in from the app developer. I believe (but may be wrong) that an app which doesn’t implement AppContainer isolation can currently access the data written by apps that do implement it. I think the intention is for it to become the default one day.

shortsunblack 3y ago

Microsoft is trying to do that with msix and a new filesystem driver that transparently restricts file system access to app. Should land into Windows 11 this year. See https://youtu.be/8T6ClX-y2AE https://youtu.be/8T6ClX-y2AE for the functionality explaination.

hervem 3y ago
And AppStore distributed application which are by default isolated, removing some feature too. (custom shortcut for example).
viraptor 3y ago
The msix story is really weird/incomplete so far. Let me just leave it at: creating services is part of msix on windows 11, but not windows server. Maybe it will be more then a toy in a few years, but we'll still have to wait for old server versions to get replaced.

Pesthuf 3y ago

Is there even a way to opt in to having a secret be accessible only for your process? Like, a way to maybe sign your executable and then use a windows api that then gets "oh. This process is made by the same vendor that created this secret, so it’ll be allowed access". It’s just ridiculous that the most trivial, unprivileged process can just steal any file and any secret accessible by the user it’s run as. Unless that secret is protected with a key derived from a separate password the user has to put in.

o11c 3y ago
I don't think it's possible on Windows. It's trivial on Unix - just make the program setgid and change the folder permissions to only allow the group. This can be nested, though that requires that the relevant program be aware of the need to walk through several levels, though often a symlink can hide that. Note that when creating such a directory setup, `chown`ing away the user requires a privileged helper utility. But you need to make such utilities anyway so the user can delete such directories. *** Important note - most other "solutions" only protect you from apps the opt in to security. A proper solution, like this one, protects from all processes running as user, except the process of note.
- viraptor 3y ago
  Or use selinux/apparmor - those have supported app sandboxing without group tricks for a long time.
  - o11c 3y ago
    Those are useless because they're opt-in, and we can't expect malicious programs to opt in. There's probably some mandatory mode but since it breaks all sorts of programs nobody can afford to use it.
    - viraptor 3y ago
      Apparmor is opt-in so it protects from exploration mostly, but selinux can definitely work with the whole system by default. It's not trivial, but you can at least prevent apps from accessing personal information unless explicitly allowed. I've been using it for years without issues. It really requires only a minimal amount of learning and you don't need to turn it off.