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--