Hello Bruno, Sorry for being to automatic for you :) I like to put few words before each advisory tough I have to admit I put my rambling through AI as often people have issues understanding me. 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 „AI tool” as a kind of advanced spellchecker. Sorry if it annoys but it helps me keep things organised and overcome my limitations.
Regarding the symlink issue I was thinking in the context of recent history with how people 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 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 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’t have enough knowledge about project internals to decide myself. Regards, — Michał 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ść napisana przez Bruno Haible <[email protected]> w dniu 30 maj 2026, o > godz. 18:53: > > Hi, > > Some AI tool wrote in the name of Michał 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. > > This is normal behaviour of symlinks. > >> Type: CWE-61: UNIX Symbolic Link (Symlink) Following > > [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. > > - the CHILD does not run with more privileges than the user that > invokes it, e.g. it is not setuid. > > - 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. > > - the CHILD program follows symlinks. > > ... > 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." > > So, by this statement, what you describe is not a security vulnerability. > >> ====================================================================== >> ATTACK SCENARIO >> ====================================================================== >> >> 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: >> >> m4/mymacro.m4 -> /home/john/.bashrc > > 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. > > "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'. > > 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. > > In summary: > - It's not a security vulnerability. > - All the "attack scenarios" that you provided rely on bad practices > that are generally avoided. > > [1] https://cwe.mitre.org/data/definitions/61.html > [2] https://seclists.org/bugtraq/2005/Jun/44 > > >
signature.asc
Description: Message signed with OpenPGP
