Comment on 700+ self-hosted Git instances battered in 0-day attacks
bort@sopuli.xyz 3 days ago
Here are the steps:
- The attacker creates a standard Git repository.
- They commit a single symbolic link pointing to a sensitive target.
- Using the PutContents API, they write data to the symlink. The system follows the link and overwrites the target file outside the repository.
- By overwriting .git/config (specifically the sshCommand), the attacker can force the system to execute arbitrary commands–
amazing.
addie@feddit.uk 3 days ago
Especially since any version of Git from the last view years has a passionate hatred of symlinks for this reason, which is a bit annoying if you’ve a legit usecase. They’re either very out-of-date, or have done some very foolish customisation…
JackbyDev@programming.dev 2 days ago
I think the ZIP standard has something similar and it causes similar problems.
PlexSheep@infosec.pub 2 days ago
It’s because of the old notion of “be generous in what you accept and strict in what you send”. I think the error is something about adding more parent directories so that part of your zip file will be extracted above the selected directory. Not all implementations of zip support this “feature”.
There are also all kinds of stupid ancient features in tar and zip from a time when hard drives were measured in megabytes or less. The latest episode of the open source security podcast talks about it.
Jason2357@lemmy.ca 2 days ago
We also have COW filesystems now. If you need large datasets in different places, used by different projects, etc, just copy them and use BTRFS or ZFS or whatever. It wont take any space and be safer. Git also has multiple ways of connecting external data artifacts. Git should by default reject symlinks.