Browsers are complex because they solve a complex problem: running arbitrary applications in a secure manner across a wide range of platforms. So any "simple" browser you can come up with just won't work in the real world (yes, that means being compatible with websites that normal people use).

I'm not even mentioning trust issues, when sensitive data is involved.

Doing anything less and hoping that companies would use your toy project is just wishful thinking. Sorry to be that guy, but please get real.

Ah yes, C++ is just one safety feature away from replacing Rust, surely, any moment now. The bizzare world C++ fanboys live in.

Every single person that had been writing C++ for a while and isn't a victim of Stockholm syndrome would be happy when C++ is put to bed once and for all. It's a horrible language only genuinely enjoyed by bad programmers.

Also I'm pretty sure that the C implementation had more man hours put into it than the Rust one.

Edit: or https://github.com/memorysafety/river

Edit 2: or https://github.com/sozu-proxy/sozu

I think the "web server" ecosystem in Rust is pretty mature by now, so you should probably state in what way your project is novel on the website.

Edit: OK, I realized that this is supposed to be an nginx/caddy replacement, so a complete, configurable web server/proxy. Maybe check out https://github.com/memorysafety/river or https://github.com/sozu-proxy/sozu

[1] https://docs.rs/axum

[2] https://docs.rs/actix-web

The Ukraine is simply too small of a country to actually win a war against Russia, all that these aid packages are doing is prolonging the war that Ukraine cannot win.

It's like saying "if only Germany had it would've won WWII". At some point they were going to run out of men anyway (they did). Sort of like how Ukraine will eventually run out of men if they continue.

"If you've never spent hours ricing your OS, you have no heart. If you still do, you have no brain."

Comments URL: https://news.ycombinator.com/item?id=41137210

Points: 2

# Comments: 0

> Sus tests for common indicators of compromise

There's a lot of stuff that Linux malware tends to do that almost no legitimate program does, this can be incorporated into the tool. Just off the top of my head, some botnet clients delete their executable after launch, in addition to being statically linked, which is an almost 100% guarantee that it's malware.

Check for deleted executables: ls -l /proc/*/task/*/exe 2>/dev/null | grep ' \(deleted\)$'

(not really reliable) check for statically linked running programs: wc -c $(grep -L libc /proc/*/task/*/maps 2>dev/null) 2>/dev/null | grep -v '^0 '

Although a malicious process can just mmap libc for giggles, and also theoretically libc can be named in a way that doesn't contain "libc". A more reliable method is parsing the ELF header in /proc/PID/exe to determine if there's an ELF interpreter defined.

You can also check for processes that trace themselves (TracerPid in status == process id), this is a common anti-debug tactic.

You can also hide the process by mounting a tmpfs on top of it's proc directory, tools like ps ignore empty proc directories due to the possibility that the process has terminated but it's proc directory is still around. This is obviously easily detectable by checking /proc/mounts or just listing empty directories with numeric names in /proc

Another heuristic can be checking /proc/PID/cmdline for two NUL bytes in a row, some malware tries to change it's process name and arguments by modifying the argv array, however they are unable to change the size of cmdline, hence having multiple NUL bytes is a viable detection mechanism. Legitimate programs do this too, but it's rather uncommon.

You can obviously combine these heuristics to make a decision whether the process is malicious, as by themselves they aren't very reliable

I wouldn't say it's a practical approach. Works for a cool demo, sure, but as an adversary I would be hesitant to use this widely.

Comments URL: https://news.ycombinator.com/item?id=40841649

Points: 45

# Comments: 45

I'm assuming the parent intended to say "if someone gained access to your user you are pwned anyways", which is true, unless you actually go to the effort of storing the secrets securely using OS-provided mechanisms. Env vars are not that.

> which isn't feasible in the real world

Well of course it isn't, how would you justify those sweet cybersecurity experts' paychecks otherwise? Not saying cybersecurity isn't important, but there's way too much snake oil in the industry nowadays (always has been?).

Unless I'm missing something, there are three scenarios where this comes up:

1. You are using a .env file to store secrets that will then be passed to the program through env vars. There's literally no difference in this case, you end up storing secrets in the FS anyway.

2. You are manually setting an env var with the secret when launching a program, e.g. SECRET=foo ./bar. The secret can still be easily obtained by inspecting /proc/PID/environ. It can't be read by other users, but so are the files in your user's directory (.env/secrets.json/whatever)

3. A program obtains the secret via some other means (network, user input, etc). You can still access /proc/PID/mem and extract the secret from process memory.

So I'm assuming that what people really want is passing the secret to a program and having that secret not be readable by anything other than that program. The proper way to do this is using some OS-provided mechanism, like memfd_secret in Linux. The program can ask for the secret on startup via stdin, then store that secret in the special memory region designed for storing secrets.