Open Source · · 1 day

AUR acroread PKGBUILD ran remote shell scripts

In July 2018, an attacker adopted the orphaned acroread package in the Arch User Repository and added a curl-to-shell install path that fetched remote scripts, installed a systemd timer, and collected host data.

The acroread incident was a small compromise, but it is a clean example of how community package metadata becomes a distribution point. Adobe Reader was not backdoored upstream, and Arch's official binary repositories were not compromised. The poisoned layer was the AUR package recipe that Arch users could pull into a normal local build.

The package was attractive because nobody was actively maintaining it. acroread wrapped an old Linux build of Adobe Reader, a native version no longer supported by Adobe. On July 8, 2018, Arch users noticed that an AUR account named xeactor had adopted the orphaned package and pushed a PKGBUILD change with the classic red flag: a remote script fetched from ptpb.pw and piped into bash. That first script was not noisy malware; it staged the rest of the intrusion. It created xeactor.service and xeactor.timer under systemd paths, set the timer to run every 360 seconds, and downloaded a second script from ptpb.pw that collected system details and posted them to Pastebin through an API key. Public analysis found no self-update mechanism and no destructive payload, but the installer path had already crossed the important line: a trusted community build recipe was executing attacker-controlled shell code during installation.

The response was fast. The report hit the aur-general list at 05:48 UTC on July 8. Six minutes later, Trusted User Eli Schwartz said the account had been suspended and the commit reverted. He then found and fixed two other packages that had been modified the same way. Arch later named the affected versions as acroread 9.5.5-8, balz 1.20-3, and minergate 8.1-2.

The important boundary is scope. AUR is user-produced content and has always carried a review burden for the user. That does not make the incident irrelevant to supply-chain history; it makes the trust lesson more precise. The attacker did not need to compromise Adobe, Arch package signing, or pacman. They needed an abandoned AUR package, a plausible maintainer action, and an install script that too many users would let run without reading.

Appendix · Affected releases

acroread aur
9.5.5-8 sha256 c1b24613…b8a57b73 download unavailable
  • The AUR cgit link now reports a bad commit reference, but the commit ID is preserved in the Arch aur-general report and contemporaneous coverage.
  • This was an AUR package recipe compromise, not an Adobe Reader upstream compromise and not a compromise of Arch's official binary package repositories.
balz aur
1.20-3 sha256 7b66661c…3feb14a7 download unavailable
minergate aur
8.1-2 sha256 52fe6126…8d5ee0b9 download unavailable

References

  1. aur-general: acroread package compromisedlists.archlinux.org
  2. aur-general: acroread package compromised responselists.archlinux.org
  3. aur-general: two other packages modified the same waylists.archlinux.org
  4. aur-general: orphaned packages were adoptedlists.archlinux.org
  5. aur-general: affected package versionslists.archlinux.org
  6. Malware found in the Arch Linux AUR repositorylwn.net
  7. Malware Found in Arch Linux AUR Package Repositorybleepingcomputer.com
  8. Arch Linux PDF reader package poisonedtheregister.com
  9. Mirrored first-stage ptpb.pw scriptgist.github.com
  10. Mirrored second-stage ptpb.pw scriptgist.github.com
  11. Arch Linux AUR Repository Found to Contain Malwaresensorstechforum.com
  12. Malware found in Arch AUR repositoryblog.desdelinux.net
  13. Malware discovered in Arch Linux AUR packageslinuxiac.com
  14. Arch AUR under fire once more as malware resurfaceslinuxiac.com
  15. Arch's AUR battles DDoS attacks and persistent malware all summerfossforce.com

Source record: oss/attacks/arch-aur-acroread/meta.yaml