undefined | Better HN

0 pointsBobbyTables24mo ago0 comments

It gets blurry at times though.

Imagine a router has a web/cli interface for setting the DHCP server’s domain name. At some point the users’s data is forwarded to a process exiting the root-owned file.

Hypothetically, If a vulnerability in the parsing of such from the config could be exploited from the end-user, that would certainly matter.

And these things always seem to be one step away from bugs that allow arbitrary injection into the config file…

(I’m amazed at the hot messes exposed with HTTP and SMTP regarding difference in CR/CRLF/LF handling. Proxy servers and even “git” keep screwing this up…)

0 comments

elnerd4mo ago

Just because you cannot see how a vulnerability can be exploited does not mean that others can. As you describe, people seem to assume that the only way the config file ends up on the server is «physically» editing it.

An anecdote: I have been struggling with exploiting a product that relies on MongoDb, I can replace the configuration file, but gaining RCE is not supported «functionality» in the embedded version as the __exec option came in a newer version.

A parser bug would be most welcome here.

bawolff4mo ago

Why stop there? Imagine a situation where the user is allowed to patch the binary.

j / k navigate · click thread line to collapse