Hacker News Reader

Comment by xena | Hacker News Reader

Writing this post: https://christine.website/blog/v-vaporware-2019-06-23

Since 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.

As 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

Many 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.

What 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

Some embedded platforms don't have memory protection, but just a big blob of global heap memory. If you forget to call free(), that memory is gone for good until you clear the entire ram and start over. Admittedly this doesn't seem to be a target use case of V, which only supports x86_64, but any serious C competitor must have meticulous memory accounting and not rely on the OS to clean up after it.

I may be wrong, but my C teacher in college told me that was a leak.

I’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#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.

> 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.

I would be surprised if embedding a string literal into a Rust program would cause a runtime dynamic memory allocation. There is no reason for that: it can be embedded into the binary as static constant-initialized data.

So I would presume the opposite: I would expect that the comparable Rust program would not fail this Valgrind test, because it would not perform any dynamic memory allocation at all.

I don't know anything about V, but I would similarly wonder why this program requires malloc().

This is true; I contemplated it but decided not to mention it. I haven’t looked into why this V program would be allocating, but I agree with you that the equivalent Rust program would not allocate for this.

I decided instead to focus just on the matter of what happens if you do allocate in such a global—which Rust doesn’t let you do directly, you deliberately have to use a trick like lazy_static which constructs on first use and then deliberately leaks so that it never has to destroy.

I admit I was wrong, I will use this information in the future to make my blogposts better.

Failing 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.

Who 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-manua...

> Most programs and their results that are in serious use are actually regulaly tested with Valgrind

See https://github.com/vlang/v/tree/master/vlib/v/tests/valgrind . The automatic memory management is work in progress right now, but we do have a growing battery of tests for it.

I currently would not use V for a long running program for exactly that reason, unless it is a very simple service and I free everything manually. That said its -autofree mode is improving daily.

Isn't all memory falls into that category then? "We are not leaking X bytes per request, we're just avoiding unnecessary free"

No, in your example that's a necessary free because you'll exhaust the system memory eventually otherwise

> 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.

Its been a while since I've read something that entertaining. Thank you.

No problem, I'm planning to write more like that, but I may end up dialing back the sarcasm a bit

Please do. I really enjoy your objective criticisms.

Hm, 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?

So you know the context. Can you please tell us, why exactly the blog author was banned?

I 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... (unfortunately I could not find an earlier snapshot, sorry)

Reply on news.ycombinator.com