Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

invalid signature tag Archivesize on rpm packages created by install4j #1635

Closed
openaudible opened this issue Apr 13, 2021 · 15 comments · Fixed by #1688
Closed

invalid signature tag Archivesize on rpm packages created by install4j #1635

openaudible opened this issue Apr 13, 2021 · 15 comments · Fixed by #1688

Comments

@openaudible
Copy link

openaudible commented Apr 13, 2021

Install4j is a popular installer maker. It appears that some or all rpm's created by them are not compatible with the latest rpm 4.16.1.3 installed with fedora. rpm works as expected in versions 4.16.0 and earlier.

Example: rpm -qvvpR install4j_linux-x64_9_0_1.rpm
returns error: run invalid signature tag Archivesize (1046)

Below is a simple Dockerfile that shows how to reproduce this:

# Dockerfile to demonstrate rpm bug with latest rpm or install4j
# To test, save this as "Dockerfile" and run:
# docker build -t testrpm . 
# to Debug in bash, docker run -it testrpm
FROM fedora:latest
WORKDIR /test
RUN yum -y install wget
RUN wget https://download-gcdn.ej-technologies.com/install4j/install4j_linux-x64_9_0_1.rpm
RUN echo "rpm -qvvpR install4j_linux-x64_9_0_1.rpm" > test.sh && chmod +x test.sh
# Run and ignore the expected error
RUN ./test.sh;exit 0
ENTRYPOINT ["/bin/bash"]

This was found by a user in issue: openaudible/openaudible#603

A work-around for is to downgrade rpm from 4.16.1.3 to 4.16.0 with the simple command: yum downgrade rpm
which you can also test by running the above docker:

docker run -it testrpm
./test.sh # fail
yum -y downgrade rpm
./test.sh # success

These are reproducible using the "latest" versions as of 4/13/2021.

@pmatilai
Copy link
Member

Yup, it's a regression introduced in 4.15.1.1 and 4.16.1.3.

Archivesize (1046) generally only exists in the main header in rpm v3 packages (a very nearly extinct species) which is how this got through. install4j is not a v3 package but a different kind of peculiarity, but we'll need to allow this as long as v3 packages are supported. Will fix.

@sshedi
Copy link
Contributor

sshedi commented Apr 29, 2021

Hi @pmatilai - any updates on this issue? It will be really helpful if it's fixed soon.

@techpavan
Copy link

+1

@neingeist
Copy link

neingeist commented May 3, 2021

I also have this problem with this software: https://download.mediathekview.de/stabil/MediathekView-latest-linux.rpm

(I haven't checked, but it's Java, so I suspect Install4J here, too)

@techpavan
Copy link

@pmatilai Could you please share if any ETA on the fix? If this takes longer, we can implement workarounds to downgrade in our applications rather than waiting for the actual fix.

@DemiMarie
Copy link
Contributor

@pmatilai Could you please share if any ETA on the fix? If this takes longer, we can implement workarounds to downgrade in our applications rather than waiting for the actual fix.

Please do not downgrade; this exposes you to a severe security hole (CVE-2021-20271) that allows for signature verification bypass and remote code execution. I will make a PR here, but please file a support ticket with install4j.

@techpavan
Copy link

@DemiMarie Thanks for the quick action. We are not direct consumers of install4j, but we consume few packages which run through this issue. Will have to probably wait for any install4j consumers to report it.

@DemiMarie
Copy link
Contributor

@DemiMarie Thanks for the quick action. We are not direct consumers of install4j, but we consume few packages which run through this issue. Will have to probably wait for any install4j consumers to report it.

You’re welcome @techpavan!

@openaudible
Copy link
Author

Install4j has fixed the issue on version 9.0.2 and higher. But not a free upgrade for many.

Software that uses the install4j installer often also includes a .sh download that can be run with -q to run it without the UI.

@sshedi
Copy link
Contributor

sshedi commented May 13, 2021

@DemiMarie thanks a lot for the fix. Any reasons behind why it is not yet merged?

@DemiMarie
Copy link
Contributor

@DemiMarie thanks a lot for the fix. Any reasons behind why it is not yet merged?

The RPM project is bottlenecked on code reviews. #1677 and #1672 have not been reviewed either, and both fix legitimate security vulnerabilities.

@pmatilai
Copy link
Member

We're bottlenecked on all manner of things, and submitting more PR's is not always the best way to help.

@sshedi
Copy link
Contributor

sshedi commented May 25, 2021

Hi @pmatilai - can you please review and take this fix on priority? this is a blocker for us.

pmatilai added a commit to pmatilai/rpm that referenced this issue May 25, 2021
…anagement#1635)

Commit d6a86b5 introduced far stricter
checks on what tags are allowed in signature and main headers than rpm
had previously seen, and unsurprisingly this introduced some regressions
on less common cases:

- On rpm v3 packages and some newer 3rd party created packages (such as
  install4j < 9.0.2), RPMTAG_ARCHIVESIZE resides in the main header
  to begin with
- In rpm 4.13 - 4.14, file IMA signatures were incorrectly placed in
  the main header.

As a quirk, permit the existence of RPMTAG_ARCHIVESIZE,
RPMTAG_FILESIGNATURES and RPMTAG_FILESIGNATURELENGTH in the main header
too provided that the corresponding signature tag is not there (so
they can reside in either but not both headers).

Initial workaround patch by Demi Marie Obenour.

Fixes: rpm-software-management#1635
@pmatilai
Copy link
Member

pmatilai commented May 25, 2021

Regressions are always a priority. It's just that world is full of priorities too. One should not think that honking the horn here will get some dark corner fixed any faster.

pmatilai added a commit that referenced this issue May 26, 2021
Commit d6a86b5 introduced far stricter
checks on what tags are allowed in signature and main headers than rpm
had previously seen, and unsurprisingly this introduced some regressions
on less common cases:

- On rpm v3 packages and some newer 3rd party created packages (such as
  install4j < 9.0.2), RPMTAG_ARCHIVESIZE resides in the main header
  to begin with
- In rpm 4.13 - 4.14, file IMA signatures were incorrectly placed in
  the main header.

As a quirk, permit the existence of RPMTAG_ARCHIVESIZE,
RPMTAG_FILESIGNATURES and RPMTAG_FILESIGNATURELENGTH in the main header
too provided that the corresponding signature tag is not there (so
they can reside in either but not both headers).

Initial workaround patch by Demi Marie Obenour.

Fixes: #1635
@sshedi
Copy link
Contributor

sshedi commented May 26, 2021

Thanks a lot @pmatilai, have a nice time ahead. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants