HardenedBSD's Random PID conflict with enable_ASLR?

10 views
Skip to first unread message

FlyingPlastics

unread,
Apr 26, 2021, 9:58:50 AM4/26/21
to HardenedBSD Users
Just installing 13-STABLE version, build 71 (latest) using disc1.iso. During hardening setup at the end of installation, I chose both random_pid and enable_aslr. However, after reboot, it's just went to kernel panic, and keeps rebooting with the error:

sysctl: oid 'kern.randompid' is read only at line 15
panic: ET_DYN_ADDR_RAND but !MAP_ASLR
cpuid = 4
time = 1619410691
__HardenedBSD_Version = 1300061 __FreeBSD_version = 1300501
version = FreeBSD 13.0-STABLE-HBSD #59 hardened/13-stable/master-n190182-39d8f0a3bd1: Sun Apr 25 11:44:05 EDT 2021
ro...@ci-01.md.hardenedbsd.org:/usr/obj/src/13-stable/amd64.amd64/sys/HARDENEDBSD
KBD: stack backtrace:
#0 0xffffffff80c52f5b at kdb_backtrace+0x6b
#1 0xffffffff80c086c6 at vpanic+0x186
#2 0xffffffff80c08493 at panic+0x43
#3 0xffffffff80b97480 at exec_elf64_imgact+0x1170
#4 0xffffffff80bbca4b at kern_execve+0x67b
#5 0xffffffff80bbc05a at sys_execve+0x5a
#6 0xffffffff810a8c9a at amd64_syscall+0x13a
#7 0xffffffff8107d39e at fast_syscall_common+0xf8
Uptime: 4s

Version: HardenedBSD 13-STABLE Build 71 64-Bit
Running on: VirtualBox 6.1.20 r143896
RAM: 8192MB
Proc: 6 Core

HBSD_KernelPanic_ASLR.jpeg

If enable_aslr was disabled in hardening option during HBSD installation, it's fine. Kernel panic also only occurs on multi-user mode, single user boot just fine.

TBH, I've been left far far behind in my understanding of C or C++ programming and codes, but digging into the kernel code where the panic message is suggest that there must be something about these codes in sys/kern/imgact_elf.c:

if (do_asr) {
    KASSERT((map->flags & MAP_ASLR) != 0,
           ("ET_DYN_ADDR_RAND but !MAP_ASLR"));
    et_dyn_addr = __CONCAT(rnd_, __elfN(base))(map,
        vm_map_min(map) + mapsz + lim_max(td, RLIMIT_DATA),
        /* reserve half of the address space to interpreter */
        maxv / 2, 1UL << flsl(maxalign));
}

With enable_asrl mode turned on, it checks and failed the kernel assertion of MAP_ASLR, but I have no idea what are the rest. Can i possibly say that ELF's loader failed to conform to ASLR?

For additional note: fresh install, just as finishing the setup. Disk is formatted as MBR UFS. I did not use ZFS because when i tried that on my FreeBSD with ZFS, pkg upgrade messed up everything (can't remember the error code, but when I reinstall FBSD with UFS and perform the same actions, it is ok. Plus I don't need ZFS for now since there is only 1 disk and all running as Guest VM in VBox).

Hopefully someone can help me understand those codes and how to fix it.
Thank you :)

Shawn Webb

unread,
Apr 26, 2021, 10:22:45 AM4/26/21
to FlyingPlastics, HardenedBSD Users
On Mon, Apr 26, 2021 at 06:58:50AM -0700, FlyingPlastics wrote:
> Just installing 13-STABLE version, build 71 (latest) using disc1.iso.
> During hardening setup at the end of installation, I chose both *random_pid*
> and *enable_aslr. *However, after reboot, it's just went to kernel panic,
> and keeps rebooting with the error:
>
> sysctl: oid 'kern.randompid' is read only at line 15
> panic: ET_DYN_ADDR_RAND but !MAP_ASLR
> cpuid = 4
> time = 1619410691
> __HardenedBSD_Version = 1300061 __FreeBSD_version = 1300501
> version = FreeBSD 13.0-STABLE-HBSD #59
> hardened/13-stable/master-n190182-39d8f0a3bd1: Sun Apr 25 11:44:05 EDT 2021
> ro...@ci-01.md.hardenedbsd.org:/usr/obj/src/13-stable/amd64.amd64/sys/HARDENEDBSD
> KBD: stack backtrace:
> #0 0xffffffff80c52f5b at kdb_backtrace+0x6b
> #1 0xffffffff80c086c6 at vpanic+0x186
> #2 0xffffffff80c08493 at panic+0x43
> #3 0xffffffff80b97480 at exec_elf64_imgact+0x1170
> #4 0xffffffff80bbca4b at kern_execve+0x67b
> #5 0xffffffff80bbc05a at sys_execve+0x5a
> #6 0xffffffff810a8c9a at amd64_syscall+0x13a
> #7 0xffffffff8107d39e at fast_syscall_common+0xf8
> Uptime: 4s
>
> Version: HardenedBSD 13-STABLE Build 71 64-Bit
> Running on: VirtualBox 6.1.20 r143896
> RAM: 8192MB
> Proc: 6 Core
>
> [image: HBSD_KernelPanic_ASLR.jpeg]
>
> If *enable_aslr* was disabled in hardening option during HBSD installation,
> it's fine. Kernel panic also only occurs on multi-user mode, single user
> boot just fine.
>
> TBH, I've been left far far behind in my understanding of C or C++
> programming and codes, but digging into the kernel code where the panic
> message is suggest that there must be something about these codes in
> *sys/kern/imgact_elf.c*:
>
> if (do_asr) {
>
> *KASSERT((map->flags & MAP_ASLR) != 0, ("ET_DYN_ADDR_RAND but
> !MAP_ASLR"));*
> et_dyn_addr = __CONCAT(rnd_, __elfN(base))(map,
> vm_map_min(map) + mapsz + lim_max(td, RLIMIT_DATA),
> /* reserve half of the address space to interpreter */
> maxv / 2, 1UL << flsl(maxalign));
> }
>
> With *enable_asrl* mode turned on, it checks and failed the kernel
> assertion of MAP_ASLR, but I have no idea what are the rest. Can i possibly
> say that ELF's loader failed to conform to ASLR?
>
> For additional note: fresh install, just as finishing the setup. Disk is
> formatted as MBR UFS. I did not use ZFS because when i tried that on my
> FreeBSD with ZFS, pkg upgrade messed up everything (can't remember the
> error code, but when I reinstall FBSD with UFS and perform the same
> actions, it is ok. Plus I don't need ZFS for now since there is only 1 disk
> and all running as Guest VM in VBox).

Hey FlyingPlastics,

Thanks for the detailed report! I'll put this at the top of my list to
research and fix. The earliest I can take a look at this will be the
beginning of May. However, as a workaround, you can leave those two
options disabled since they're technically both enabled by default in
HardenedBSD. We need to update the installer to just remove those
hardening options since the ASLR option enables FreeBSD's ASR (the L
left out on purpose) and we already enable PID randomization.

Out of curiosity, would you mind filing a bug report in our GitLab
instance[1]? That way, I can properly attribute you (via referencing
the bug number in the commit message) as the person who found the bug.

I'll keep you updated as to my progress.

[1]: https://git.hardenedbsd.org/

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc

FlyingPlastics

unread,
Apr 26, 2021, 11:29:08 AM4/26/21
to HardenedBSD Users, Shawn Webb, HardenedBSD Users, FlyingPlastics

Done, #41[1]. Thanks for speedy response, Shawn, I appreciate that :D

Reply all
Reply to author
Forward
0 new messages