5 ms·

Well, Windows Defender actively interferes with security software development. I've noticed that lots of developers either disable Windows Defender or try to w

by Randor 6y ago

Well, Windows Defender actively interferes with security software development. I've noticed that lots of developers either disable Windows Defender or try to whitelist the development folders. Whitelisting doesn't always work... Windows Defender will block certain behaviors such as token stealing and in-memory attacks. Also... software developers often have 'test-signing' enabled and all kinds of other security risks that are unique to software development.

zinekeller 6y ago
True, it is often hard to secure these things when the ultimate goal is to produce a new binary, however there are obvious low-hanging fruit that I've always encountered regardless of the host OS used. The encouragement of using a read-write directory (I'm looking at Eclipse and Android Studio of all things, but the majority of development tools are guilty of these) are fully writable (especially executables) without administrative/superuser permissions. Seriously, you want Android SDK on a user-writable place by default? That's questionable at best and contrary to any sysadmins who are the ones to lock these executables to well-known places.
- londons_explore 6y ago
  The days of multiple users logging into the same machine and each having a writable home directory are pretty much over. 2020 mostly consists of single human machines with a user account and a root account. All the private data is stored in the user account. There is nothing extra of value in the root account. The 1980's security paradigm's no longer really work.
  - zinekeller 6y ago
    I do sometimes laugh at the naïvety of some here. Sorry, what? There is no value of actually securing systems here? It is frustrating to know that in real life, some developers are not really concerned about the security of their dev machines. Try to install Android Studio (make sure to initialise it!) or Eclipse on your system and tell me where it put its executables. Go and indulge in the horror that your local adb binary can be replaced silently without your knowledge. When most mobile operating systems are designed to isolate components together, we collectively are hindering effective security by allowing these low-hanging fruit on our systems. Sorry but often I just see countless developers that are not that concerned about security and then ask themselves why are users irresponsible about security.
    - londons_explore 6y ago
      So the ADB binary can be replaced silently by anything running as your user account? But anything running as your user account can also steal your ssh keys and gain persistence via cron or .bash_profiles or any of a multitude of other methods. How does a writable ADB binary let an attacker do anything more than they could do before?
      - zinekeller 6y ago
        > But anything running as your user account can also steal your ssh keys and gain persistence via cron or .bash_profiles or any of a multitude of other methods. How does a writable ADB binary let an attacker do anything more than they could do before? I have no answers on Linux sadly (but you can disable user-side cron so that you can ensure that cron entries are not editable), but on Windows you can lock down your system by not allowing to run executables from non-whitelisted directories (AppLock), so you can only execute programs from specific directories. Does not really prevent stupidity ("I accidentally run NotAVirus.exe from our build directory") but you frustrate attackers from running their own executable (especially that most drive-by attacks rely on the Download folder or Temporary folder being executable). Of course, you need to monitor your build directories for harmful executables but you significantly reduce the attackers' footprint into the system. Additionally SSH keys can be stored in a format where you need to have an active password in order to decrypt them.
    - danielheath 6y ago
      The point you were replying to is: Who cares that you can replace the adb binary? Once you have code execution as my user, you have access to my browser data (banking, google developer accounts), my ssh keys, etc. We need capability-based privilege separation on network-connected machines.
      - zinekeller 6y ago
        > Once you have code execution as my user The question is "how"? If you are indeed targeted by state-level attackers, there should be more precautions because you are actively attacked. However, I have stated that "there are low-hanging fruits". I have written up a more extensive reply (https://news.ycombinator.com/item?id=25914440 https://news.ycombinator.com/item?id=25914440) but the short answer is that you can actually prevent code execution on arbitrary areas on Windows. Upon further research, I now know that there is an analogous equivalent (and maybe competition) for Linux: AppArmor and SELinux. However, I will still see someone replying "there is no solution to this mess" despite having a solution, just unused by developers. It is made harder by other developers who by their choice makes security-conscious developers' lives harder. > We need capability-based privilege separation on network-connected machines. Yes, you're correct on that. But abandoning reliable-but-unused security for shiny new thing seems wrong on so many levels.
cik 6y ago
There are lots of things that interfere with software development. A shocking amount of my work happens in VMs, or on a dedicated "I don't trust you" workstation that re-pxe boots itself nightly. It shouldn't have to be this way, but there's ample evidence that it needs to be.

by Randor 6y ago

zinekeller 6y ago

True, it is often hard to secure these things when the ultimate goal is to produce a new binary, however there are obvious low-hanging fruit that I've always encountered regardless of the host OS used. The encouragement of using a read-write directory (I'm looking at Eclipse and Android Studio of all things, but the majority of development tools are guilty of these) are fully writable (especially executables) without administrative/superuser permissions. Seriously, you want Android SDK on a user-writable place by default? That's questionable at best and contrary to any sysadmins who are the ones to lock these executables to well-known places.

londons_explore 6y ago
The days of multiple users logging into the same machine and each having a writable home directory are pretty much over. 2020 mostly consists of single human machines with a user account and a root account. All the private data is stored in the user account. There is nothing extra of value in the root account. The 1980's security paradigm's no longer really work.
- zinekeller 6y ago
  I do sometimes laugh at the naïvety of some here. Sorry, what? There is no value of actually securing systems here? It is frustrating to know that in real life, some developers are not really concerned about the security of their dev machines. Try to install Android Studio (make sure to initialise it!) or Eclipse on your system and tell me where it put its executables. Go and indulge in the horror that your local adb binary can be replaced silently without your knowledge. When most mobile operating systems are designed to isolate components together, we collectively are hindering effective security by allowing these low-hanging fruit on our systems. Sorry but often I just see countless developers that are not that concerned about security and then ask themselves why are users irresponsible about security.
  - londons_explore 6y ago
    So the ADB binary can be replaced silently by anything running as your user account? But anything running as your user account can also steal your ssh keys and gain persistence via cron or .bash_profiles or any of a multitude of other methods. How does a writable ADB binary let an attacker do anything more than they could do before?
    - zinekeller 6y ago
      > But anything running as your user account can also steal your ssh keys and gain persistence via cron or .bash_profiles or any of a multitude of other methods. How does a writable ADB binary let an attacker do anything more than they could do before? I have no answers on Linux sadly (but you can disable user-side cron so that you can ensure that cron entries are not editable), but on Windows you can lock down your system by not allowing to run executables from non-whitelisted directories (AppLock), so you can only execute programs from specific directories. Does not really prevent stupidity ("I accidentally run NotAVirus.exe from our build directory") but you frustrate attackers from running their own executable (especially that most drive-by attacks rely on the Download folder or Temporary folder being executable). Of course, you need to monitor your build directories for harmful executables but you significantly reduce the attackers' footprint into the system. Additionally SSH keys can be stored in a format where you need to have an active password in order to decrypt them.
  - danielheath 6y ago
    The point you were replying to is: Who cares that you can replace the adb binary? Once you have code execution as my user, you have access to my browser data (banking, google developer accounts), my ssh keys, etc. We need capability-based privilege separation on network-connected machines.
    - zinekeller 6y ago
      > Once you have code execution as my user The question is "how"? If you are indeed targeted by state-level attackers, there should be more precautions because you are actively attacked. However, I have stated that "there are low-hanging fruits". I have written up a more extensive reply (https://news.ycombinator.com/item?id=25914440 https://news.ycombinator.com/item?id=25914440) but the short answer is that you can actually prevent code execution on arbitrary areas on Windows. Upon further research, I now know that there is an analogous equivalent (and maybe competition) for Linux: AppArmor and SELinux. However, I will still see someone replying "there is no solution to this mess" despite having a solution, just unused by developers. It is made harder by other developers who by their choice makes security-conscious developers' lives harder. > We need capability-based privilege separation on network-connected machines. Yes, you're correct on that. But abandoning reliable-but-unused security for shiny new thing seems wrong on so many levels.

cik 6y ago

There are lots of things that interfere with software development. A shocking amount of my work happens in VMs, or on a dedicated "I don't trust you" workstation that re-pxe boots itself nightly. It shouldn't have to be this way, but there's ample evidence that it needs to be.