>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.

lucky for them, its an exploit script, not enterprise code.

all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.

edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming

▲

StableAlkyne a day ago | parent | next [-]

It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.

Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.

▲

john_strinlai a day ago | parent [-]

agreed regarding the RHEL version!

i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!

the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.

evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.

amazingly HN-like to be upset about a variable name

▲

akdev1l a day ago | parent | next [-]

Disagree because to run the PoC you really ought to understand what it’s doing.

And this code is not readable at all. It is failing at letting people confirm the exploit easily.

▲

john_strinlai a day ago | parent [-]

>Disagree because to run the PoC you really ought to understand what it’s doing.

that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.

>It is failing at letting people confirm the exploit easily.

it confirms the exploit incredibly easy. just run it, and you get confirmation.

▲

akdev1l a day ago | parent [-]

what the blog says and what the code does are two different things.

For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

▲

john_strinlai a day ago | parent | next [-]

>I need to know what the code does before I run it.

its literally code meant to exploit your system. you should be running it in an environment built for that already.

you dont test exploit pocs on your daily driver.

▲

akdev1l 18 hours ago | parent [-]

> you dont test exploit pocs on your daily driver.

Do you just like making fake points and pretending other people said them?

	▲	john_strinlai 13 hours ago \| parent [-]
		go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it. you said "I need to know what the code does before I run it.". you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc. if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.

▲

asdfaoeu a day ago | parent | prev [-]

While your at it you can enter your credit card details to see if they've been leaked.

▲

asdfaoeu a day ago | parent | prev [-]

I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.

▲

Xirdus 2 days ago | parent | prev [-]

I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.

▲

john_strinlai 2 days ago | parent [-]

id imagine that they received more than just the poc in the report they received

▲

Xirdus a day ago | parent [-]

That doesn't make reviewing the POC any less valuable.

▲

john_strinlai a day ago | parent [-]

what value do you believe renaming the variable from "g" to something else provides the linux maintainers?

	▲	Xirdus a day ago \| parent [-]
		It makes the exploit code more readable. We all love to laugh at C folks but for real, even Linux kernel maintainers care about readability.