How, in this century, did anyone think passing http url params as env vars was an acceptable design? Fix is incomplete & goahead is unfixable.https://twitter.com/elttam/status/942630494054752256 …
It's unfixable (without breaking all existing usage) because the bug is in the public interface by which parameters are passed, not the implementation.
-
-
Blocking LD_PRELOAD is a band-aid for one of the worst environment-control-based attack vectors. But there are unboundedly many possible attacks.
-
... assuming an unbounded space of env vars might influence the exec'd program? I agree that arbitrarily blocking LD_PRELOAD is a band-aid. But env vars are just inputs... why deprecate wholesale just because a few of them have huge effect on ld.so? Systematic fix feels possible
End of conversation
New conversation -
-
-
Oddly, I cannot find anywhere in the CGI spec where it says to pass query variables that way. I'm wondering where the idea even came from.
-
From PHP.
-
The idea is that the user writes CGI as shell scripts the same way you write (hideous, legacy, deprecated) PHP, using $paramname for query params.
-
Gack. Now the question is, how much breaks if you implement the spec only (QUERY_STRING has the query params)?
-
All existing code written for GoAhead. That's why I called it unfixable.
-
It's analogous to if you made a C-like language where the only input primitive was gets(). There'd be no way to fix it without overhauling all existing code.
-
Well, two mmap() and a signal handler. But no _practical_ way, anyway. :)
-
At best that lets you safely abort the program on excess input; there's still no way to cleanly recover.
- 11 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.