On Tue, Dec 20, 2016 at 11:31:57AM +0100, Jiri Kosina wrote:
> On Tue, 20 Dec 2016, Jiri Kosina wrote:
>
> > I stay totally unconvinced that such kind of countermeasure brings any
> > value whatsoever. Could you please bring up a particular usecase, where
> > you have complete control over kerne
On Tue, 20 Dec 2016, Jiri Kosina wrote:
> I stay totally unconvinced that such kind of countermeasure brings any
> value whatsoever. Could you please bring up a particular usecase, where
> you have complete control over kernel memory, and still the only
> possible exploit factor is redirecting
On Tue, 20 Dec 2016, Greg KH wrote:
> > Sorry, I really don't get this.
> >
> > If kernel memory can be easily changed (which is assumed here), why bother
> > with all this? I'll just set current->uid to 0 and be done.
>
> Because you don't want your current process to uid 0, you want some
> ot
On Mon, Dec 19, 2016 at 02:34:00PM +0100, Jiri Kosina wrote:
> On Fri, 16 Dec 2016, Greg KH wrote:
>
> > > You seem to be targeting a situation where the kernel memory can be
> > > easily changed, but filesystem content cannot (if it could - the
> > > attacker would simply replace /sbin/hotplug).
On Fri, 16 Dec 2016, Greg KH wrote:
> > You seem to be targeting a situation where the kernel memory can be
> > easily changed, but filesystem content cannot (if it could - the
> > attacker would simply replace /sbin/hotplug).
>
> Correct, like an embedded system with a read-only system partition
On Fri, Dec 16, 2016 at 12:02:33PM +1100, NeilBrown wrote:
> On Thu, Dec 15 2016, Greg KH wrote:
>
> > Hi all,
> >
> > Here's a proof-of-concept patch series that tries to work to address the
> > issue of call_usermodehelper being abused to have the kernel call any
> > userspace binary with full r
On Thu, Dec 15 2016, Greg KH wrote:
> Hi all,
>
> Here's a proof-of-concept patch series that tries to work to address the
> issue of call_usermodehelper being abused to have the kernel call any
> userspace binary with full root permissions.
>
> The issue is that if you end up getting write access
On Wed, Dec 14, 2016 at 10:28:18PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
>
> On Wed, Dec 14, 2016 at 7:50 PM, Greg KH wrote:
> > So, anyone have any better ideas? Is this approach worth it? Or should
> > we just go down the "whitelist" path?
>
> I think your approach is generally better
Hi Greg,
On Wed, Dec 14, 2016 at 7:50 PM, Greg KH wrote:
> So, anyone have any better ideas? Is this approach worth it? Or should
> we just go down the "whitelist" path?
I think your approach is generally better than the whitelist path. But
maybe there's yet a third approach that involves futz
On Wed, Dec 14, 2016 at 11:25 AM, Mark Rutland wrote:
>
> Hi,
>
> On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote:
>> The issue is that if you end up getting write access to kernel memory,
>> if you change the string '/sbin/hotplug' to point to
>> '/home/hacked/my_binary', then the next ue
Hi,
On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote:
> The issue is that if you end up getting write access to kernel memory,
> if you change the string '/sbin/hotplug' to point to
> '/home/hacked/my_binary', then the next uevent that the system makes
> will call this binary instead of th
Hi all,
Here's a proof-of-concept patch series that tries to work to address the
issue of call_usermodehelper being abused to have the kernel call any
userspace binary with full root permissions.
The issue is that if you end up getting write access to kernel memory,
if you change the string '/sbi
12 matches
Mail list logo
