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
