#9 Support filesystem extended attributes in tmpfs

Closed
opened 2 months ago by shawn.webb · 2 comments

We use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD’s exploit mitigation toggling with the ports tree, extended attribute support needs to be added to tmpfs.

We use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD's exploit mitigation toggling with the ports tree, extended attribute support needs to be added to tmpfs.
shawn.webb added the
enhancement
label 2 months ago
shawn.webb added the
help wanted
label 2 months ago
shawn.webb self-assigned this 2 months ago
shawn.webb added the
in progress
label 2 months ago
shawn.webb commented 1 month ago
Owner

This is now finished in hardened/current/master and pending MFC after some smoke tests with Poudriere.

This is now finished in `hardened/current/master` and pending MFC after some smoke tests with Poudriere.
shawn.webb added the
needs mfc
label 1 month ago
shawn.webb commented 3 weeks ago
Owner

This work is now completed.

This work is now completed.
shawn.webb closed this issue 3 weeks ago
shawn.webb referenced this issue from a commit 3 weeks ago
HBSD: Pull in libarchive/libarchive@65a23f5dbee4497064e9bb467f81138a62b0dae1 From the commit in libarchive: ``` Fuzzing with CRCs disabled revealed that a call to get_uncompressed_data() would sometimes fail to return at least 'minimum' bytes. This can cause the crc32() invocation in header_bytes to read off into invalid memory. A specially crafted archive can use this to cause a crash. An ASAN trace is below, but ASAN is not required - an uninstrumented binary will also crash. ==7719==ERROR: AddressSanitizer: SEGV on unknown address 0x631000040000 (pc 0x7fbdb3b3ec1d bp 0x7ffe77a51310 sp 0x7ffe77a51150 T0) ==7719==The signal is caused by a READ memory access. #0 0x7fbdb3b3ec1c in crc32_z (/lib/x86_64-linux-gnu/libz.so.1+0x2c1c) #1 0x84f5eb in header_bytes (/tmp/libarchive/bsdtar+0x84f5eb) #2 0x856156 in read_Header (/tmp/libarchive/bsdtar+0x856156) #3 0x84e134 in slurp_central_directory (/tmp/libarchive/bsdtar+0x84e134) #4 0x849690 in archive_read_format_7zip_read_header (/tmp/libarchive/bsdtar+0x849690) #5 0x5713b7 in _archive_read_next_header2 (/tmp/libarchive/bsdtar+0x5713b7) #6 0x570e63 in _archive_read_next_header (/tmp/libarchive/bsdtar+0x570e63) #7 0x6f08bd in archive_read_next_header (/tmp/libarchive/bsdtar+0x6f08bd) #8 0x52373f in read_archive (/tmp/libarchive/bsdtar+0x52373f) #9 0x5257be in tar_mode_x (/tmp/libarchive/bsdtar+0x5257be) #10 0x51daeb in main (/tmp/libarchive/bsdtar+0x51daeb) #11 0x7fbdb27cab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #12 0x41dd09 in _start (/tmp/libarchive/bsdtar+0x41dd09) This was primarly done with afl and FairFuzz. Some early corpus entries may have been generated by qsym. ``` Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org> Sponsored-by: SoldierX
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.