[sr #111048] Add a syntax check to code snippets

[Martin Nilsson]

Follow-up Comment #5, sr #111048 (group autoconf):

[comment #4 comment #4:]
> Note that adding a syntax check before each check will certainly make
"configure" somewhat slower.  Should we prefer increasing security at the cost
of something slower?

You only need to run the syntax checker if the test fails to compile.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [sr #111048] Add a syntax check to code snippets

[Po Lu]

Fabrice BAUZAC-STEHLY  writes:

> Follow-up Comment #3, sr #111048 (group autoconf):
>
> I agree, it's not so easy.
>
> On CMake side, I think they are considering adding an "escape hatch" that
> would not go unnoticed either.
>
> For Autoconf, maybe we could add a separate macro (with a very explicit name)
> for syntax checks like "case 0 ... 5".  A malicious contributor would have a
> harder time explaining why they would create a syntax check for checking the
> availability of a system feature like landlock, as was the case with XZ
> Utils.
> https://www.man7.org/linux/man-pages/man7/landlock.7.html
>
> My 2 cents...

In Autoconf scripts, it's frequently the case that the absence of a
feature is signaled by arranging for a syntax error to be compiled if
certain preprocessor macros be undefined.  Take Gnulib's macro for
detecting Clang:

# AC_CHECK_DECL executed conditionally.  Therefore append the extra tests
# to AC_PROG_CC.
AC_DEFUN([gl_COMPILER_CLANG],
[
dnl AC_REQUIRE([AC_PROG_CC])
  AC_CACHE_CHECK([whether the compiler is clang],
[gl_cv_compiler_clang],
[dnl Use _AC_COMPILE_IFELSE instead of AC_EGREP_CPP, to avoid error
 dnl "circular dependency of AC_LANG_COMPILER(C)" if AC_PROG_CC has
 dnl not yet been invoked.
 _AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM([[
   #ifdef __clang__
   barfbarf
   #endif
   ]],[[]])
],
[gl_cv_compiler_clang=no],
[gl_cv_compiler_clang=yes])
])
])

I think this practice was historically more widespread than today, but
nevertheless syntax errors are perfectly legitimate constructs in any
build-time feature test, and demanding that their existence be indicated
by a special macro would break numerous existing Autoconf scripts while
not producing any appreciable improvement in security.  Doing so would
be throwing the baby out with the bathwater, and a distraction from the
plenty of other venues a malicious maintainer could exploit to conceal
code, of which mending this specific instance would penalize Autoconf
users to a much greater degree than malefactors, while also setting a
precedent for this "whack-a-mole" approach to security, which, fueled by
paranoia rather than concrete consideration, is not likely to be
effective before an adversary in the position of trust enjoyed by
package maintainers.

[sr #111048] Add a syntax check to code snippets

[Fabrice BAUZAC-STEHLY]

Follow-up Comment #4, sr #111048 (group autoconf):

Note that adding a syntax check before each check will certainly make
"configure" somewhat slower.  Should we prefer increasing security at the cost
of something slower?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111048] Add a syntax check to code snippets

[Fabrice BAUZAC-STEHLY]

Follow-up Comment #3, sr #111048 (group autoconf):

I agree, it's not so easy.

On CMake side, I think they are considering adding an "escape hatch" that
would not go unnoticed either.

For Autoconf, maybe we could add a separate macro (with a very explicit name)
for syntax checks like "case 0 ... 5".  A malicious contributor would have a
harder time explaining why they would create a syntax check for checking the
availability of a system feature like landlock, as was the case with XZ
Utils.
https://www.man7.org/linux/man-pages/man7/landlock.7.html

My 2 cents...


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111048] Add a syntax check to code snippets

[Collin Funk]

Follow-up Comment #2, sr #111048 (group autoconf):

[comment #0 original submission:]
> So the CMake project is considering adding a preliminary syntax check
> (with a verbose error message) in addition to the full check (which
> fails rather silently), so that such disabling does not go unnoticed:

Feel free to correct me if I am missing something, but I don't see how that is
possible.

How would you check for certain compiler extensions which may cause syntax
errors if unsupported?

Something like GCC case ranges:


int
main (void)
{
  switch (2)
{
case 0 ... 5:
  return 0;
default:
  return 1;
}
}


Would cause a syntax error on other compilers. I don't see a way of
differentiating that from a case like that CMake script.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111048] Add a syntax check to code snippets

[Fabrice BAUZAC-STEHLY]

Follow-up Comment #1, sr #111048 (group autoconf):

Sorry, this SR was from me.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111048] Add a syntax check to code snippets

[anonymous]

URL:
  

 Summary: Add a syntax check to code snippets
   Group: Autoconf
   Submitter: None
   Submitted: Fri 05 Apr 2024 07:44:13 AM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: fbau...@amadeus.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Fri 05 Apr 2024 07:44:13 AM UTC By: Anonymous
Hello,

As you may know, an attack related to XZ Utils (lzma) has been
discovered:

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

The malicious account has disabled a feature by sneakily forging an
always-failing code.  This has been done by introducing a syntax error
in a CMake file (a dot at the beginning of a line):

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7

So the CMake project is considering adding a preliminary syntax check
(with a verbose error message) in addition to the full check (which
fails rather silently), so that such disabling does not go unnoticed:

https://gitlab.kitware.com/cmake/cmake/-/issues/25846

This makes me think that Autoconf does compilation checks similar to
that of CMake, and therefore an attacker could similarly, sneakily
disable a feature.

Should Autoconf similarly add a syntax check?  I'm leaving this open
question to the community.

Thanks!

Best regards
Fabrice








___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/