search

AnarchyTools / atbuild

The Anarchy Tools build tool
Apache License 2.0
6 stars 1 forks source link

Is system considered harmful? #106

Open drewcrawford opened 8 years ago

drewcrawford commented 8 years ago

Pinging @AnarchyTools/build-tool-admins @AnarchyTools/package-manager-admins on this, since it's security.

We use posix system pretty extensively (and also in atpm and various attools.). In atbuild the decision is historical: There was a bug preventing us from using NSTask, that bug was fixed upstream, but then we decided to move off Foundation so we never went back. But we also never made a decision, and our "workaround" became permanent.

system has the issue that it passes text to the shell interpreter. If the text is built from user input (which it is in practice), then a maliciously-crafted package could insert a rm -rf or worse by populating the right fields in the build.atpkg.

....however, a maliciously-crafted package is capable of doing all kinds of things anyway, for example by just calling rm -rf from the shell tool which we wrote for that purpose. This is the double-edged sword of allowing scripting in the first place.

Do we consider "shell breakout" from a malicious atpkg to be a security issue? My feeling is no, but I think we should make an actual justified decision on the record.

It's worth pointing out that we can view different cases differently. e.g. while atbuild has the shell tool designed for shell breakout, atpm does not, but it still allows shell breakout via "vulnerability". Is that case different than atbuild? Our .attool extensions are another sort of weird case where they don't themselves have a shell tool built into them, but are commonly used from inside atbuild so it isn't clear if their use of system is a "vulnerability".

dunkelstern commented 8 years ago

I think the complete system execv and popen API should probably be wrapped in a more swift like way. Probably something in atfoundation. System itself is of course not optimal but i would not see it as a vuln in every case. I would prefer to encapsulate external calls in a better API though but i would not make it a high priority because getting that API right will take some time.