The C compiler revealed the following buffer overflow:
../super.c: In function ‘buttonup’:
../super.c:1457:35: warning: ‘%s’ directive writing up to 1200 bytes into a region of size 1196 [-Wformat-overflow=]
1457 | (void) sprintf(Cmd, "SUPERCMD=%s", cmd);
| ^~
In file included from /usr/include/stdio.h:970,
from ../localsys.h:21,
from ../super.h:18,
from ../super.c:12:
In function ‘sprintf’,
inlined from ‘buttonup’ at ../super.c:1457:12:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:30:10: note: ‘__builtin___sprintf_chk’ output between 10 and 1210 bytes into a destination of size 1205
30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
The effect of this bug would be to overwrite the first five bytes of the
subsequent object in the mapped global data segment.
Looking at the relevant variables for each of the binary packages
currently available in the archive, it would seem to have either no
impact or, rarely, an altered diagnostic message.
These are the affected (potentially partially overwritten) objects for
each of the current binary packages, in the case that a long command
line is accepted by super.
- Diagnostic message (that will include a NUL byte later in buffer due
to padding or otherwise):
3.30.3-1_arm64 00000000000b8210 0000000000000400 B authInitMsg2
3.30.3-1_armhf 000aca50 00000400 B authInitMsg2
3.30.3-2.2_armhf 000b3a5c 00000400 B authInitMsg2
3.30.3-2.2+b1_arm64 00000000000c4280 0000000000000400 B authInitMsg2
3.30.3-2.2_loong64 00000000000c39b0 0000000000000400 B authInitMsg2
3.30.3-2.2_riscv64 00000000000a3958 0000000000000400 B authInitMsg2
3.30.3-2.2_s390x 00000000000aa210 0000000000000400 B authInitMsg2
3.30.3-2+b1_arm64 00000000000c4280 0000000000000400 B authInitMsg2
3.30.3-2+b1_armel 000c3a50 00000400 B authInitMsg2
3.30.3-2+b1_armhf 000b3a50 00000400 B authInitMsg2
3.30.3-2+b1_s390x 00000000000a9210 0000000000000400 B authInitMsg2
3.30.3-2+b2_armhf 000b3a5c 00000400 B authInitMsg2
3.30.3-2+b2_riscv64 00000000000a4958 0000000000000400 B authInitMsg2
3.30.3-2+b3_arm64 00000000000c4280 0000000000000400 B authInitMsg2
- Subsequently overwritten in full before use:
3.30.3-2.2_ppc64el 00000000000c4280 0000000000001005 b Home.3
3.30.3-2+b1_ppc64el 00000000000c4280 0000000000001005 b Home.3
- Subsequently overwritten in full before use:
3.30.3-1_amd64 00000000000ad7a0 00000000000004b6 b SafePath.5
3.30.3-1_i386 000b0fe0 000004b6 b SafePath.5
3.30.3-2.2_amd64 00000000000ae780 00000000000004b6 b SafePath.5
3.30.3-2.2_i386 000b0fe0 000004b6 b SafePath.5
3.30.3-2+b1_amd64 00000000000ad7a0 00000000000004b6 b SafePath.5
3.30.3-2+b1_i386 000b0fe0 000004b6 b SafePath.5
3.30.3-2+b1_mips64el 00000000000ca138 00000000000004b6 b SafePath.5
3.30.3-2+b1_mipsel 000c9448 000004b6 b SafePath.5
3.30.3-2+b2_amd64 00000000000ae780 00000000000004b6 b SafePath.5
Therefore I believe this is worth fixing in the next source code
release, and would justify a new source release, but is not a serious
concern for any users of existing binary packages in the archive.
The following patch to the upstream code fixes this issue:
diff --git a/super.c b/super.c
index 5a14fe4..52cd7fa 100644
--- a/super.c
+++ b/super.c
@@ -1435,7 +1435,7 @@ char *cmd; /* name of command being started */
else
(void) sprintf(SafePath, "PATH=%s", SAFE_PATH);
- if (strlen(cmd) > sizeof(Cmd)-5) {
+ if (strlen(cmd) > sizeof(Cmd)-sizeof("SUPERCMD=0")) {
Error(0, 0, "$$\n\tRidiculously long original string.\n");
return NULL;
}