Eskimo North

Someone has figured out how to exploit rpc.rstatd to crash the shell server:

BAD TRAP: cpu=2 type=9 rp=f21e0a1c mmu_fsr=3aa rw=2
MMU sfsr=3aa: Protection Error on supv data store at level 3
regs at f21e0a1c:
psr=1e0009c6 pc=f00a5568 npc=f00a556c
y: 30000000 g1: f00a0ce0 g2: 1 g3: f00403a8
g4: 0 g5: f21e1000 g6: 326 g7: efffb400
o0: f00e220c o1: 9 o2: f21e0acc o3: f9981e
o4: 1e4000c1 o5: f009f740 sp: f21e0a68 ra: ff135db0
pid 8742, `rpc.rstatd': Data access exception
kernel write fault at addr=0x2014, pme=0x1eabbaa
MMU sfsr=3aa: Protection Error on supv data store at level 3
rp=0xf21e0a1c, pc=0xf00a5568, sp=0xf21e0a68, psr=0x1e0009c6, context=0xda2
g1-g7: f00a0ce0, 1, f00403a8, 0, f21e1000, 326, efffb400
Begin traceback... sp = f21e0a68
Called from f00a6fc8, fp=f21e0ad0, args=ffffffff f1bc82c8 159483a 0 0 0
Called from f00a3264, fp=f21e0b30, args=ff31b4a0 efffb000 1000 1 0 0
Called from f00a092c, fp=f21e0b98, args=ff31b4a0 efffb000 0 0 0 fb08d248
Called from f00a12b4, fp=f21e0c08, args=ff31b4a0 efffb000 ffffd000 fb38fca0 0 f2
1e0c94
Called from f00a375c, fp=f21e0cb8, args=ff31b4a0 1000 0 0 efffb000 ff31b768
Called from f0109028, fp=f21e0d18, args=efffb000 ff31b4a0 1000 0 1 efffb000
Called from f0102fe4, fp=f21e0d80, args=efffb400 1 0 0 ff331318 f183e4e4
Called from f0005d84, fp=f21e0de8, args=9 f21e0e44 f00e2fe0 326 1 2226
Called from f0040f68, fp=f21e0e90, args=1 3 5 0 efffe000 1
Called from f01037c4, fp=f21e0ef0, args=f21e1410 efffbd18 40 efffb400 0 f01d6c00
Called from f000595c, fp=f21e0f58, args=10005 f21e0fb4 efffbd18 0 0 0
Called from ef7019f0, fp=efffbb90, args=0 0 20000 0 0 0
End traceback...
panic on cpu 2: Data access exception
syncing file systems... [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20
[1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1] 20 [1]
20 give up!
07768 low-memory static kernel pages
07052 additional static and sysmap kernel pages
00004 dynamic kernel data pages
01992 additional user structure pages
00000 segmap kernel pages
00000 segvn kernel pages
00304 current user process pages
01728 user stack pages
18848 total pages (4712 chunks)

It always barfs trying to write a kernel memory address of addr=2014 (that's a hex address).
I've looked over the code and there are only reads and no writes of kernel memory.

I put firewall rules in place blocking the port that rpc.rstatd listens to; it stopped the crashes
for a day but somehow they've gotten around this and I don't know how.

I've recompiled rpc.rstatd with gcc and created a separate I&D "pure text" binary to see if
this helps but I really want to understand how this is being exploited and fix it. If anyone has
any information please e-mail nanook@eskimo.com or post here.

Thanks.

When I firewalled the rpc.rstatd port; the crashes stopped, for a day, and then resumed. The crash dumps were still showing an rpc.rstatd thread running and a write to the same location page faulting.

I disabled rpc.rstatd altogether, and it still crashed, and still showed a rpc.rstatd thread running and write at the same location during the crash.

Then I noticed that it's always the same process ID as well, it seems that the crash dump isn't even being written properly and it's just reprinting stuff previously saved.

So now I do not know what is causing this. In single user mode it seems to run stable indefinitely, even doing heavy compiling like when rebuilding kernels from source.