Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Most serious” Linux privilege-escalation bug ever is under active exploit

arstechnica.com

Post reply on HN
Print view View original

151–160 of 218 posts

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#151

Post by TheSpiceIsLife »

hollander wrote: post #149
TheSpiceIsLife wrote: post #93

Earlier quoted context omitted.

The solution is for people to stop using blockquote formatting for text and reserve it for it's intended puprose of quoting code and retaining formatting.

The solution is to wrap text for mobile devices. It's easy to test for screen size.

HN already has that, it's called

   Not doing this when you paste in a block of written material
Or just doing something like this to indicate you pasted in a block of text

"Or just using quotes"

   for chicken in chicken:
    chicken = chicken['chicken']
    chick = chicken['chicken']
    print ( chicken + '; ' + chicken )
        return "blockquoting is for code"

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#152

Post by snvzz »

kentonv wrote: post #114
drieddust wrote: post #109

>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required. [1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...

Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-securit... While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case…

> This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel.

Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#153

Post by snvzz »

pjmlp wrote: post #127
drieddust wrote: post #109

>However that's hard to do when the vast majority of kernel bugs come from vendor drivers, not the upstream Linux kernel, Stoep said. Doesn't this actually validate Andrew Tannenbaum's argument[1] over 25 years ago when he said monolithic operating systems are inherently insecure and a rethink is required. [1] https://groups.google.com/forum/m/?fromgroups#!topic/comp.os...

While it is in part true, no amount of band-aid solutions will fix the issue of using C.

A small TCB will still be key, regardless of language.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#154

Post by pm215 »

problems wrote: post #110
tytso wrote: post #107

Earlier quoted context omitted.

The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).

I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.

When I first set up fail2ban it was because I got annoyed that the machine on my desk was making regular "clunk...clunk...clunk" noises from the hard disk as it wrote another failed-auth attempt to the log every second or so...

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#155

Post by cyphar »

stass wrote: post #104
orblivion wrote: post #75

Earlier quoted context omitted.

It's sad that security information and news is so confusing as it is, but thank you for trying to improve it. I'll try to remember your site.

Some operating systems like FreeBSD and (I think) Debian have this functionality built in without the need for external service. So it depends on what you are using. RedHat had a similar functionality as well AFAIR.

SUSE-based distros have it as well (zypper tells you about CVE patches and how severe they are).

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#156

Post by qwertyuiop924 »

i336_ wrote: post #97
qwertyuiop924 wrote: post #65

Earlier quoted context omitted.

I genuinely doubt he'll notice. Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers. Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.

-F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)

...which actually does handle truncation properly. For some reason.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#157

Post by drieddust »

sheer_horror wrote: post #134
drieddust wrote: post #133

Earlier quoted context omitted.

Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.

Yep but my argument still holds true especially in the era of IoT risks are now becoming physical. Bugs earlier used to only impact people financially, emotionally but now risks are physical.

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#158

Post by pjmlp »

snvzz wrote: post #153
pjmlp wrote: post #127

Earlier quoted context omitted.

While it is in part true, no amount of band-aid solutions will fix the issue of using C.

A small TCB will still be key, regardless of language.

10% small TCB size vs 100% of the complete code.

Which one will a security minded person pick?

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#159

Post by snvzz »

sheer_horror wrote: post #134
drieddust wrote: post #133

Earlier quoted context omitted.

Yeah not sure what happened. Somehow I ended up looking at wrong article. I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems. Another argument is modularity which would have allowed better testing hence lesser chances of bugs.

Despite your erroneous reply, you still hit 4th most upvoted comment thanks to the pro-open source sentiment here.

Why do you think it is erroneous?

Re: “Most serious” Linux privilege-escalation bug ever is under active exploit

#160

Post by snvzz »

wbl wrote: post #124
kentonv wrote: post #114

Earlier quoted context omitted.

Looks like you are quoting from: http://arstechnica.com/security/2016/09/linux-kernel-securit... While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case…

seL4 does not have these kinds of errors. By shrinking the TCB, you make it possible to do hardcore verification. The challenge is in extending to larger systems and composition.

Worth noting that as of Genode's latest release, a lot of progress has been made in that regard.
Post reply on HN