Re: Symlink-Follow File Overwrite in aclocal --install (CWE-61)
MichaĆ Majchrowicz via Discussion list for automake <[email protected]> Sun, 31 May 2026 10:14:32 +0200
| Newsgroups | gmane.comp.sysutils.automake.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_37408924-9FE7-4F50-AC3D-2A4AAC837890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Bruno, Sorry for being to automatic for you :) I like to put few words before = each advisory tough=20 I have to admit I put my rambling through AI as often people have issues = understanding me.=20 I am not a native English speaker and at the same time even in my native = language I have a tendency to write incoherent sentences and miss some stuff. Anyway to = overcome my problems I use an =E2=80=9EAI tool=E2=80=9D as a kind of advanced = spellchecker. Sorry if it annoys but it helps=20 me keep things organised and overcome my limitations. Regarding the symlink issue I was thinking in the context of recent = history with how people=20 were using Gemini CLI in the pipeline or last Shai Halud (or whatever it = was called) attack. Where problems with GitHub CI process allowed attackers to leak = authentication tokens and as a result gain access to repo itself. I was thinking about a = scenario where this issue is used to overwrite such tokens. I have too little knowledge about CI pipelines myself but wanted to = report this issue=20 just in case it might have an impact. If you think such scenarios are = unlikely than yes this is not a security issue. During my research I often encounter = issues that=20 whether they are security bugs or not often depends on context. My = approach is to report them anyway and let the developer decide the impact as in = most cases I don=E2=80=99t have enough knowledge about project internals to decide = myself. Regards, =E2=80=94 Micha=C5=82 Majchrowicz / Offensive Security Engineer / PhD eWPTX PGP: D52A 5289 8256 006D 5E05 BAC6 79EA 0072 F4E1 9D57 AFINE sp. z o.o. Al. Jerozolimskie 146C, 02-305 Warszawa https://www.afine.com <https://www.afine.com/> > Wiadomo=C5=9B=C4=87 napisana przez Bruno Haible <[email protected]> w = dniu 30 maj 2026, o godz. 18:53: >=20 > Hi, >=20 > Some AI tool wrote in the name of Micha=C5=82 Majchrowicz: >> We are writing to report a symlink-following file overwrite = vulnerability >> in the aclocal tool shipped with GNU automake. When the --install = flag is >> used, aclocal copies system macro files into the project's local m4 >> directory without checking whether the destination path is a symbolic >> link. An attacker who can place a symlink in the m4 directory can = cause >> aclocal to overwrite an arbitrary file on the developer's system. We >> confirmed the issue against the current git HEAD (commit 658cceb3c) = and >> with the latest release (1.18.1) on x86_64 Linux. >=20 > This is normal behaviour of symlinks. >=20 >> Type: CWE-61: UNIX Symbolic Link (Symlink) Following >=20 > [1] references [2], which says: > " > - the CHILD has a "standalone" design, i.e. its normal mode of > operation is to be run by an interactive user, or a script on > behalf of the user. >=20 > - the CHILD does not run with more privileges than the user that > invokes it, e.g. it is not setuid. >=20 > - the CHILD program assumes that the user calling the program has > control over all files that are specified as arguments, i.e. the > specified filenames are trusted. >=20 > - the CHILD program follows symlinks. >=20 > ... > Note that the four conditions for the CHILD, if treated alone, are = not > normally regarded as a security vulnerability: there aren't any > privilege boundaries being crossed, and the filenames are under the > control of the user." >=20 > So, by this statement, what you describe is not a security = vulnerability. >=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> ATTACK SCENARIO >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> An attacker who can write one file into the project's m4/ directory - >> for example through a pull request, a supply chain compromise of a >> shared macro repository, or CI automation that processes contributed >> branches before human review - plants a symbolic link in place of a >> legitimate macro file: >>=20 >> m4/mymacro.m4 -> /home/john/.bashrc >=20 > A user who runs "a pull request" in their own environment would be an > idiot anyway, not only because of 'aclocal --install', but because > changes to the Makefiles may contain arbitrary commands. >=20 > "Supply chain compromise of a shared macro repository": Sure, supply > chain compromises do exist (e.g. 'npm', 'cargo', etc.). The general > advice therefore is to watch your supply chain. This is unrelated > to 'aclocal'. >=20 > CI automation typically uses a fresh virtual machine for each CI run, > so that possible damage caused by untrusted code is limited to this > virtual machine. >=20 > In summary: > - It's not a security vulnerability. > - All the "attack scenarios" that you provided rely on bad practices > that are generally avoided. >=20 > [1] https://cwe.mitre.org/data/definitions/61.html > [2] https://seclists.org/bugtraq/2005/Jun/44 >=20 >=20 >=20 --Apple-Mail=_37408924-9FE7-4F50-AC3D-2A4AAC837890 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1SpSiYJWAG1eBbrGeeoAcvThnVcFAmob7egACgkQeeoAcvTh nVeTLA//YDDXaOYXvrKgWs03uOor/v7W+uLq4JbRf02KK6t67mhQw3HyR/0/q7re jpFEWo/vUUF5YPeS3We4eQqJKVkTTRjeRReYfHFI2c6RSzu6HRA334453hj70zPT 4Io7A2KoWs0JXamzdB3Zikw/599UwTZxDuDaN6itleSr9hWb2X7mhTraJwszdkMx OuFa1TJsmf7YMkKyDSUxYVl1TZshseQaHi6OV1uYsWUXe1KkXW/VbAZ6joodZ/wk LOQJND3XgVeooOP4EgWzMvHPMj20aX+Yh/GC2UzSm0ZfO/RSUO8i9Rgb89T0VddK /jfQT8n5kLX4JjWTKBT+2HgeNnn/E63JwYFQ8iygO5fVjLuR63V3GHTdS3qn1PHK MxkCZSiKqPchaeqi1624nXKxzbRIuB2kMIp/nrYZd57S95oH1lK57PgiOBZ/yYVq VmOiynNM37Z6BQmn7vJu+ttQC/dXdWXU3SUre6v6vaLd+4+enXyWYdfIvT0tZzx7 jHvgR8YXlF715JUUCUSxmuUOSgMs5OkKK/A46Uix8aTKY8jInm1W6cYvoSh0ArnU uylBYg5H/QS+UCBViLw3j1A7KqJSNiHANdk0oKtVg36LxII71YcVO9pQPqv0X/Mj vFtn+52WUhLHPaDymqMh/NegWekra6dXa7irHKyLF7cR3O4lpxM= =Bsjw -----END PGP SIGNATURE----- --Apple-Mail=_37408924-9FE7-4F50-AC3D-2A4AAC837890--