Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Agreed, adding to this, if a malicious actor already has the ability to execute arbitrary LUA scripts on your redis instance, then you are probably already pretty screwed.


I've got nothing bad to say about the vuln research here, I'm sure it's a great bug, just this CVSS stuff is a farce and everyone seriously working in the field seems to agree, but we're just completely path-dependently locked in to it.


If the Lua "sandbox" is actually a decent sandbox, then the most you could do before was DoS the box. DoS <<<<< RCE


I see downvotes but no explanations why -- what is wrong with my claim?


I believe the context is that the CVE is that this bypasses the sandbox entirely; so in this specific case this is a real, full-blown RCE. Your comment makes it seem at a glance that you're saying it's a DOS at worse.


Thanks for replying, but my comment is not saying that at all -- it's pushing back on someone making the claim that the new CVE is no worse than what could already be done, by pointing out that what could already be done was (presumably) only a DoS, while the new CVE is full RCE.

I've reread my comment and the parent comment, and I don't understand how this is not clear?


The Lua interpreter in Redis doesn’t allow you to run regular code, you can’t event to “print”, not to talk about load libraries as in regular Lua interpreter. It’s a sanboxed one with very minimal operations you can do


The vulnerability appears to _be_ a Lua sandbox escape.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: