Recent changes to patches

7z wrapper in /usr/bin jeopardizing the effort to hide password from commandline parameters

Michal Ambroz — Thu, 03 Oct 2024 06:31:09 -0000

Hello,
this has been already reported to Fedora package:
https://bugzilla.redhat.com/show_bug.cgi?id=2316073

the 7z (/usr/libexec/p7zip/7z) is trying to clear the password from the process command attributes as soon as it is not needed anymore.
Unfortunately in Fedora we have a wrapper /usr/bin/7z which is doing nothing else than executing /usr/libexec/p7zip/7z , which will still reveal the password.

Running for example:
7z a test.7z test.dd -mx=9 -ppassword123

Will result in this process listing:
rebus 2713410 0.0 0.0 228500 3612 pts/24 S+ 10:45 0:00 /usr/bin/sh /usr/bin/7z a test.7z test.dd -mx=9 -ppassword123
rebus 2713411 121 0.4 1079920 154904 pts/24 R+ 10:45 0:08 /usr/libexec/p7zip/7z a test.7z test.dd -mx=9 -p*****

Possible solutions:
1) using the wrapper with a "exec statement to replace the current process"
2) use just a link file
3) compile the 7z in such a way that it can be placed directly to /usr/bin/7z and search the 7z.so in some expectable library location

As using the link file would break 7z, and changing the 7z location needs much more work on the code, I guess using the exec is the right way to go.

The usr/bin/7z should read like this:

!/usr/bin/sh

exec "/usr/libexec/p7zip/7z" "$@"

Reproducible: Always

Steps to Reproduce:
1. run in one terminal this loop
while true ; do ps aux|grep -e '[7]z' ; done | less

prepare some reasonably big file
dd if=/dev/zero of=test.dd bs=1M count=100
try to zip the file with password
7z a test.7z test.dd -mx=9 -ppassword123

Actual Results:
rebus 2713410 0.0 0.0 228500 3612 pts/24 S+ 10:45 0:00 /usr/bin/sh /usr/bin/7z a test.7z test.dd -mx=9 -ppassword123
rebus 2713411 121 0.4 1079920 154904 pts/24 R+ 10:45 0:08 /usr/libexec/p7zip/7z a test.7z test.dd -mx=9 -p*****

Expected Results:
rebus 2713411 121 0.4 1079920 154904 pts/24 R+ 10:45 0:08 /usr/libexec/p7zip/7z a test.7z test.dd -mx=9 -p*****

-------------------- cut here -------------
For completenes
Using link file results in this error:
sudo rm /usr/bin/7z
sudo ln -s /usr/libexec/p7zip/7z /usr/bin/7z
$ 7z a test.7z test.dd -mx=9 -ppassword123

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz (806EC),ASM,AES-NI)

Can't load './7z.dll' (./7z.so: cannot open shared object file: No such file or directory)

ERROR:
7-Zip cannot find the code that works with archives.

#30 p7zip fails to decompress valid bzip2 file

Sam Tansy — Fri, 08 May 2020 14:00:01 -0000

Out of curiosity where did you find that? I mean bzip2 1.0.6 is like 10 yeayrs old and lbzip2 was in craddle back then...

#30 p7zip fails to decompress valid bzip2 file

Igor Pavlov — Fri, 08 May 2020 10:07:51 -0000

The things are more complcated.
There was old bug in bzip2 code.
lbzip2 used that bug for some extra features.
Then the bug was fixed in bzip2, but they extended the decoder to support extended archives created by lbzip2.
But they extended bzip2 decoder even more than required by lbzip2. So now bzip2 decoder is super extended, and that over-lbzip2 is not supported by current 7zip.

#30 p7zip fails to decompress valid bzip2 file

Sam Tansy — Fri, 08 May 2020 04:54:48 -0000

It is artificial file but rationale behind that was that lbzip2 allows 18008 MFT selectors

// @ LBZIP2_SRC/encode.c
  union {
    struct {
      uint8_t selector[18000 + 1 + 1];
      uint8_t selectorMTF[18000 + 1 + 7];
      uint32_t num_selectors;
      uint32_t num_trees;
      (...)

when bzip2 format 18002

// @ $BZIP2_SRC/bzlib_private.h
#define BZ_G_SIZE   50
#define BZ_MAX_SELECTORS (2 + (900000 / BZ_G_SIZE))
(...)

As said before:

The nSelectors relaxation is probably something we want to get out asap, so
people can unbzip2 all files again they could before (even if they were
technically "broken").

It's a question to lzbip2 devs why they violated format rather than to bzip2 team.

#30 p7zip fails to decompress valid bzip2 file

Igor Pavlov — Fri, 01 May 2020 11:24:07 -0000

So is it artificial file?
Actually I don't like that code in Bzip2-1.0.8 decoder, but if it allows such archives, maybe 7-Zip also can allow it.

#30 p7zip fails to decompress valid bzip2 file

Sam Tansy — Tue, 28 Apr 2020 11:48:49 -0000

I know it was long time ago but as this is still an issue I will try to upload it. This script is given in a way that is not exactly easy to decode.
Here is base64 encoded payload.bz2.gz:

PAK="H4sIAAAAAAACA3OKyrA0dIxUC460+znBh4GByY2BQYCJgYdB//8DhuEORsEoGAWjYBSMglEw\
CkbBKBgFo2AUjIJRwJa54KxJWpzek66ChQq1nxVmAABZl5ZRLBAAAA=="

echo $PAK | base64 -d | gzip -dc > payload.bz2

To decode it one needs run above script or download and gunzip attachment.

@Robert Luberda: I'm not sure whether simply allowing 32767 as they are not going to be used in format anyway.Bip2-1.0.8 alows them but discards excess (1.0.8 release) but this belongs to devs.

#37 interest in oss-fuzz?

Berkeley Churchill — Sat, 21 Dec 2019 05:50:46 -0000

Sorry, should clearly say "p7zip" not "ossec-hids"... I'm making this offer to a few projects!

interest in oss-fuzz?

Berkeley Churchill — Sat, 21 Dec 2019 05:45:21 -0000

OSS Fuzz is a google project that supports open source projects by fuzzing. It allows Google to find and report bugs, especially security bugs, to the project. I'm willing to work on writing fuzzers for ossec-hids and integrating with oss-fuzz, if this would be welcome by the maintainers. You would see me writing some fuzzing harnesses and making pull requests to merge them in to the project, and a few regression tests to make sure that the fuzzing harnesses are working properly. Then, you would get reports from google with anything the fuzzer finds.

Is this something that would be welcome for this project?

#36 Fix archivers/p7zip endianness detection

Igor Pavlov — Sat, 12 Aug 2017 16:54:32 -0000

As I suppose they made some changes in some old version of p7zip, but later they have discovered the problem. So they wrote another patch for another patched version?
But original p7zip 16.02 must work OK as I suppose.
CpuArch.h is used in Windows and in Posix. Why to link some external <endian.h>, if averything works ok without that <endian.h>?

Fix archivers/p7zip endianness detection

Josh — Sat, 12 Aug 2017 10:41:12 -0000

Patch to replace the architecture list with <endian.h> developed by Donovan Watteau. Discussion thread on the OpenBSD ports@ mailing list begins here