On Sat, Mar 18, 2023 at 03:06:43PM +0100, p...@delphinusdns.org wrote: > >Synopsis: segmentation fault in opensmtpd mda > >Category: system > >Environment: > System : OpenBSD 7.2 > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022 > > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > Architecture: OpenBSD.arm64 > Machine : arm64 > >Description: > I would have waited another week after contacting Gilles at his address > and at his openbsd.org address last week, but we're out of -beta and I'd like > to see this addressed before release. It may already be too late though. > I've found a way to crash the mda that is forked from opensmtpd before the > exec. It is a specially crafted .forward file that does this. In the worst > case scenario it will fill up /var with smtpd.core's when the > kern.nosuidcoredump sysctl is set to 3. The queue files are stuck in queue > and have to be removed either with smtpctl remove or until they time out. > A lot of these could fill /var with corefiles quicker.
Actually if the kern.nosuidcoredump is anything but 3, chances are the corefile will be in the attackers $HOME, which for a hacker could be a lot more exciting by being able to garner information out of this core. Thank god for getpwnam_shadow() in OpenBSD meaning forkmda() in smtpd.c can't get snippets of the password database in the .core. However systems like FreeBSD in the portable version may not be so lucky. It does a chdir() to $HOME of the user so chances are that's where the core file rests in peace later. I wanted to add this to make the severity more important for this bug. Best Regards, -peter > >How-To-Repeat: > Here is the "exploit" code that I stuck into my .forward, I also gave > this to Gilles. <cut exploit> > You would apply this with cc -g -o makeforward makeforward.c and then fill the > .forward with ./makeforward > ~/.forward > > >>> Please do not try this out on your account, make a test account <<< > >Fix: > I think some struct envelopes need to be memset to 0's (zeroized). But > where exactly that is I don't know. > > > dmesg: > see earlier messages >
