8 ms·
What caused them to ban you?
by pilaf 6y ago
What caused them to ban you?
- xena 6y agoWriting this post: https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
- discmonkey 6y agoIts been a while since I've read something that entertaining. Thank you.
- dTal 6y agoSince you're here... >Do not shell out to arbitrary commands in the standard library for any reason. If an attacker can somehow run code on a server with a V binary that uses the download_file function, they can replace curl with a malicious binary that is able to do anything the attacker wants. I don't understand this threat model. If an attacker is in a position to replace /usr/bin/curl with a malicious binary, surely you're already pwned? And surely an attacker could just as easily switch out libcurl.so as the curl binary? I just can't make sense of any threat model which treats the OS as untrusted.
- xena 6y agoAs written it's it won't just call /usr/bin/curl, but the first curl in $PATH. Not to mention just hardcoding /usr/bin/curl isn't portable (Android/NixOS don't have a /usr/bin like you expect). Also take a look at this: https://christine.website/blog/OVE-20190623-0001 https://christine.website/blog/OVE-20190623-0001
- a1369209993 6y agoMany computers are misconfigured to include "." (the current working directory at the time of execve) in PATH, which allows a trivial privilege escalation and/or native code execution for any attacker that can write a executable file named "curl" in any directory that the target process can be convinced to cd into. Shelling out also means the process will unexpectedly stop working if /usr/bin/curl disappears (or wasn't installed in the first place), whereas that's a known and expected issue for libcurl.so and there are established tools (eg `ldd /bin/program`) for tracking such dependencies.
- shawnz 6y agoWhat is the problem with the "still reachable" memory report in Valgrind? That's not a leak, that is just skipping an unnecessary free() that will happen anyway when the process exits
- xena 6y agoI may be wrong, but my C teacher in college told me that was a leak.
- chrismorgan 6y agoI’m with shawnz. If it’s a global/static, and you’re the entire process, freeing it is altogether a waste. Actually, if you have actual destructors, it’s even potentially hazardous. Rust deliberately eschews static constructors and destructors due to their problems, so I presume it would fall foul of this test of yours as well. It offers this explanation: https://doc.rust-lang.org/1.6.0/complement-design-faq.html#there-is-no-life-before-or-after-main-no-static-ctorsdtors https://doc.rust-lang.org/1.6.0/complement-design-faq.html#t... (link is to the Rust 1.6 docs; in theory by the next release the content was ported to the main site, but I can’t find it and suspect it got lost at some point). Now if you’re a library, then having the ability to deinitialise your library might be useful. Probably not, but it might be.
- acqq 6y agoFailing Valgrind is surely not a state in which neither a serious program should be nor the code produced by it. Most programs and their results that are in serious use are actually regulaly tested with Valgrind and therefore don't have such elementary failures, unless they aren't maintained. It doesn't have to be "a library" -- as soon as you want to test it, you don't want it to fail the trivial tests. Nobody wins anything by keeping that in that state.
- shawnz 6y agoWho says having "still reachable" memory in your Valgrind output is a "fail" though? Look at this excerpt from the Valgrind manual: > Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. So, by default, Memcheck won't report such blocks individually. https://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks https://www.valgrind.org/docs/manual/mc-manual.html#mc-manua...
- delian66 6y agoHm, are you sure that attacking the V's playground at the time and publishing info, that others could use to attack it, did not have something to do with your ban?
- lightgreen 6y agoSo you know the context. Can you please tell us, why exactly the blog author was banned?
- delian66 6y agoI do not know the full context, because at the time I was not involved with the V project. I did notice then though that the playground was taken down, and there is this: https://web.archive.org/web/20191223200601/https://christine.website/blog/OVE-20190623-0001 https://web.archive.org/web/20191223200601/https://christine... (unfortunately I could not find an earlier snapshot, sorry)
- lightgreen 6y agoOK, looks like the "security advisory" was posted before the playground was fixed, and with no good to anybody. That's nasty.
- xena 6y agoIt was posted after the project owner confirmed it was down and would stay down.
- lightgreen 6y agoI hardly believe that. If that was true, I'd expect this fact (that the server will stay down) to be mentioned in the blog post. The blog only says "playground server stopped replying" and "The V creator acknowledged the issue and admitted the machine was compromised".
- xpuente 6y ago> So the compiler with "zero dependencies" is a dynamically linked binary > with dependencies on libpthread and libc. And requires an OS to run too. That's another dependency! This and memory leak, seems quite forced. Ad homminens doesn't help either.