segfault installing packages (in very strange edge cases) #1833
Assignees
Labels
Comments
|
What's very suspicious is the "len=224" argument. It's supposed to be the digest length in bytes. |
|
That'd be IMA signatures, which are a new thing in CS9. Probably this issue: |
|
The code in rpmsignfiles.c should at least check if the signature sizes match and not just use the size of the last signature... Anyway, the sizes are implicit through the string array, so we can simply ignore the RPMTAG_FILESIGNATURELENGTH from the header and do the right thing in the implementation. We can make fi->signaturelen an array, add fi->maxsignaturelen and add a new hex2bin variant that first calculates the max signature size, puts in in fi->maxsignaturelen and then converts the individual entries populating fi->signaturelen. |
|
Basically like the veritysigs implementation... I didn't know about those. |
|
Yup. Keeping the hex-encoded strings as such in memory (as done in the rough patch in bugzilla) is would be a terrible waste of memory. |
|
...on a related note, we should only bother with keeping this stuff in memory if IMA plugin is loaded, it's a non-trivial amount of memory even in binary form for which we have absolutely zero use if they don't get used. Ditto with fsverity. |
|
Is this an exploitable vulnerability? This also shows why IMA and fsverity signatures belong in the main header, where they cannot be tampered with. |
|
Never mind, I see there's an update on the RHBZ. |
|
To work around, one of the following should do:
|
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Nov 26, 2021
, RhBug:2018937) ECDSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Nov 29, 2021
, RhBug:2018937) ECDSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Nov 29, 2021
, RhBug:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Dec 2, 2021
, RhBug:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Dec 6, 2021
, RhBug:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Dec 6, 2021
, RhBug:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Dec 13, 2021
, RhBug:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
that referenced
this issue
Dec 13, 2021
At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. Luckily the signatures are stored as strings so we can calculate the actual lengths at runtime and ignore the stored constant length info. Extend hex2bin() to optionally calculate the lengths and maximum, and use these for returning IMA data from the rpmfi(les) API. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: #1833
pmatilai
added a commit
that referenced
this issue
Dec 13, 2021
Commit a79d7ae had two major flaws: Firstly, it negletted to update the part that copies the data in place to match the new layout where data lengths are not always equal, and the for loop would overshoot its bounds on data shorter than maximum. Secondly, rpmfilesFSignature() would now crash on packages with no IMA signatures because fi->signaturelengths is not allocated. Take care not to change API behavior wrt *len return value: set to zero if no signatures are present.
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is handled with special zero-block at zero offset whose size is known beforehand. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is handled with special zero-block at zero offset whose size is known beforehand. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is handled with special zero-block at zero offset whose size is known beforehand. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is handled with special zero-block at zero offset whose size is known beforehand. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 8, 2022
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 8, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 9, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 9, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Feb 10, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833
pmatilai
added a commit
that referenced
this issue
Feb 11, 2022
At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: #1833
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Jun 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833 (cherry picked from commit 07f1d31)
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Jun 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833 (cherry picked from commit 07f1d31)
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Jun 7, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833 (cherry picked from commit 07f1d31)
dmnks
pushed a commit
to dmnks/rpm
that referenced
this issue
Jun 8, 2022
…g:2018937) At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: rpm-software-management#1833 (cherry picked from commit 07f1d31)
dmnks
pushed a commit
that referenced
this issue
Jul 1, 2022
At least ECDSA and RSA signatures can vary in length, but the IMA code assumes constant lengths and thus may either place invalid signatures on disk from either truncating or overshooting, and segfault if the stars are just so. As we can't assume static lengths and attempts to use maximum length have proven problematic for other reasons, use a data structure that can actually handle variable length data properly: store offsets into the decoded binary blob and use them to calculate lengths when needed, empty data is simply consequtive identical offsets. This avoids a whole class of silly overflow issues with multiplying, makes zero-length data actually presentable in the data structure and saves memory too. Add tests to show behavior with variable length signatures and missing signatures. Additionally update the signing code to store the largest IMA signature length rather than what happened to be last to be on the safe side. We can't rely on this value due to invalid packages being out there, but then we need to calculate the lengths on rpmfiles populate so there's not a lot to gain anyhow. Fixes: #1833 (cherry picked from commit 07f1d31)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi all!
I'm getting segfaults from rpm when installing packages in osbuild. The set of circumstances that cause the segfault are very strange and very sensitive to changes, so I might be giving a lot of useless information here.
The issue happens with rpm 4.16.1.3 on CentOS Stream 9. I haven't managed to reproduce it on other distros or distro versions, even with the same packages, though some package versions might differ. It also seems to be sensitive to the following:
I managed to get a backtrace, though I haven't managed to reproduce it in an interactive environment so I haven't managed to look around. Here's the bt:
If you'd like to reproduce it, install osbuild (version 40 or newer, for CS9 support) and run the attached manifest as root:
The manifest is in JSON but I renamed it to TXT to attach it to the issue.
The
--checkpoint buildflag will save a checkpoint of the first part of the build so repeated runs will be faster. By default these are saved in.osbuildin the current working directory, but you can change that with the--storeoption.I've been trying to pinpoint the cause for a couple of days now and it's making less sense the more I look at it.
Let me know if there's any more information you need or if I can help in any way.
rpm-segfault.txt
The text was updated successfully, but these errors were encountered: