IRC channel logs

<solid_black>ok, I have a way to panic Mach on i386, and the same should give me a kernel write primitive on x86_64, which is easily escalated into full access

<solid_black>is such a vulnerability known?

<youpi>very most probably not

<solid_black>I haven't tested on x86_64 though, maybe I should verify that it works & I can get root

<youpi>we want to fix it anyway

<damo22>solid_black, finding more 0days?

<damo22>im glad youre working for us

<damo22>:P

<damo22>ie not against us

<solid_black>:)

<damo22>solid_black: can i pm you for a sec

<solid_black>sure

<solid_black>youpi: what am I supposed to put into sources.list for hurd-amd64 -- people.debian.org/~sthibault or deb.debian.org/debian-ports?

<Denis>hello all. I managed to trigger a kernel crash in Hurd, is there a specific procedure to report it, or I just send the details to bug-hurd@?

<youpi>solid_black: better use debian-ports, to get the most up to date packages

<youpi>solid_black: actually, use both :)

<solid_black>yeah, I've just tried that

<youpi>some packages I built them by hand quite roughly

<youpi>so I cannot upload them to debian-ports

<solid_black>can't quite get it to upgrade though; it hangs on dpkg-preconfigure with errors about bogus ports in exec & ext2fs

<youpi>it seems preconfigure has a hang yes, you can just kill it

<solid_black>ideally we should debug the bogus ports things

<solid_black>but that'd need debuginfo

<youpi>we don't have debuginfo?

<youpi>for what package?

<solid_black>I thought we don't have debuginfo for all of them? and you said that's because you're bootstrapping and that doesn't produce debuginfo packages?

<solid_black>maybe I misunderstood

<solid_black>let me see

<youpi>the packages on people don't have symbols indeed

<youpi>but packages fro mdebian-ports are properly built

<solid_black>just killing it seems to have worked indeed

<solid_black>oh, there's already a gdb? is that with flavio's patches?

<solid_black>cool

<youpi>yes

<youpi>getting debugging tools is always a priority :)

<solid_black>"gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration"

<youpi>yes, probably worth having a look

<youpi>it doesn't seem to be preventing from most debugging functions

<solid_black>why are gnumach-image-1.8-486 and gnumach-image-1.8-486-dbg two separate packages?

<solid_black>is the latter built with MACH_DEBUG?

<damo22>dbg has kdb

<solid_black>is there a debuginfo package for the regular gnumach-image?

<damo22>dbg != debuginfo

<solid_black>yes, I'd expect it to be called gnumach-image-1.8-486-dbgsym

<damo22>is the kernel really stripped?

<solid_black>is it not? I'd expect it to be, like all binaries are

<solid_black>over here in the Alpine-based distro, 'gnumach' contains the stripped kernel image, gnumach-dbg contains the debuginfo for it, and the proper debuglink is injected into /boot/gnumach

<youpi>the gnumach debian packaging is really old, it doesn't follow current practices and thus doesn't generate a dbgsym package

<youpi>contribution welcome ;)

<damo22>Denis: if its a zero-day bug, probably email our maintainer before making it public, otherwise if its just a crash, just mail it to bug-hurd

<youpi>dh_strip: warning: Could not find the BuildID in debian/gnumach-image-1.8-486/boot/gnumach-1.8-486

<youpi>so apparently it's not a packaging issue

<solid_black>totally worked!

<solid_black> https://i.imgur.com/DXP2f6H.png

<solid_black>damo22 youpi: ^

<damo22>ok

<damo22>hopefully we can fix these and they become much more rare

<damo22>although we have a russian hacker to help

<solid_black>:D

<gnucode>solid_black: congrats on finding another 0 day vulnerability.

IRC channel logs

2024-02-23.log