4 ms·
Even without --user-agent, you can still pipe 'echo -e "GET ...\rnHost: ... "' through nc, or even telnet. Therefore, we obviously need to patch echo (and all
by anyfoo 8y ago
Even without --user-agent, you can still pipe 'echo -e "GET ...\rnHost: ... "' through nc, or even telnet.
Therefore, we obviously need to patch echo (and all echo shell builtins) to refuse to output strings containing "GET", "POST", "HTTP", or "Host:".
- colordrops 8y agoOoh boy I'm imagining some bureaucratic version of an operating system that uses this sort of security up and down the entire stack like some rube Goldbergian contraption to whack a mole a particular vulnerability. Like an operating system designed by doctor Seuss.
- zrm 8y ago> Therefore, we obviously need to patch echo (and all echo shell builtins) to refuse to output strings containing "GET", "POST", "HTTP", or "Host:". Unfortunately it is also possible to do this using file redirection or to write a new program that will make a TCP connection and send arbitrary data through it, making it necessary to do the same for all editors, compilers and interpreters. That sounds like a lot of work though (there are many such programs), so maybe we ought to just patch the kernel to prohibit any of those strings from being written to a file descriptor. There can't be that many false positives.
- ezoe 8y agoWhy stop there? The user can easily modify the kernel to disable such prevention measures for malicious usage. We must have a regulation to require a hardware level detection and prevention features of curl which all hardware vendors must follow.
- asynch8 8y agooh god stop some politician might see this and take you for being srs
- craftinator 8y agoBut users have fingers, which can be used to disable or subvert said "features". Thus, those fingers are just gonna have to go. They're a security risk, and security risks are against the regulations.