Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun wrote: > On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > > > The obvious additional client would be a remote kernel, but as the > exploit > > program that I posted shows, it could just as easily be an unprivileged > > process. Y

Re: netmsg can now exec files (sort of)

I've figured out why the patched exec server didn't work with mmap, and just opened a bug on it, with a fix attached. So now I've got a working, mmap-less exec server that burns a lot of extra RAM (each process gets its own private copy of the C library), but lets me execute files across a netmsg

[bug #48946] exec server can't properly load binaries without a memory manager object

URL: Summary: exec server can't properly load binaries without a memory manager object Project: The GNU Hurd Submitted by: baccala Submitted on: Tue 30 Aug 2016 01:46:17 AM GMT Categor

Re: Denial of service attack via libpager

On Mon, Aug 29, 2016 at 11:20:47AM +0200, Richard Braun wrote: > In addition, I've just thought about something else : if we handle > multiple clients, how do we make sure that two kernels, caching the > same file, don't just completely corrupt its content ? We'd need > some kind of cooperation to

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > I should elaborate on what I found with exec. After I fixed the problem > with the exec server mmap'ing the library's ELF headers, it just got on a > little bit further in the process, and then croaked when it tried to mmap > the

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > So we still have to mmap across the network. We certainly don't want to > avoid mmap's entirely for program text and (especially) for shared > libraries. Although I admit that it would be best to detect when the mmap > fails and