Hacker News new | past | comments | ask | show | jobs | submit login

Most (if not all) major cloud providers do this if you use their provided images. If you want to avoid agents, then go with a provider that allows you to upload your own ISO which means you can install a vanilla OS.

And use disk encryption. I've encountered situation when hoster mounted root partition and wrote his scripts inside after OS installation. Fortunately it broken network, so I noticed it. Very sneaky and unexpected.

There is an important qualification, however: the AWS SSM agent does not start a network server at all (it connects to their API endpoint) and it doesn't do anything if you don't add the appropriate permissions to the instance's role.

The GCP agent similarly does not listen to the network.

Both the Google and AWS agents are written in Go, too, so they're unlikely to have the classic C/C++ errors, more likely to use libraries rather than reinventing the wheel, and using a higher-level language often makes the logic easier to understand. Neither of those are foolproof or prevent logic errors, of course, but I would still expect a lower bug density all other things being equal.

> more likely to use libraries rather than reinventing the wheel

I love programming in go, but I disagree with this point. The golang library ecosystem is absolutely less mature compared to C++.

Rust and Go are a pleasure to write in, but they don’t magically fix every problem and frequently CREATE problems because they’re still under development. In this case, the missing auth header vuln has nothing to do with the underlying language.

Yeah, it's definitely not a simple good/bad decision. My thought is that it's more likely that a Go library would be more likely to have implemented something like a mandatory auth check but the counterpoint is that if such a library were vulnerable it would affect potentially a very large number of services.

The problem with C++, is that while std::{array, string, vector} exist, and there are compiler options that make operator[]() behave just like at(), there are still lots of people that will happily use char * instead.

> so they're unlikely to have the classic C/C++ errors

Two things here :

- This vulnerability is a logic error (no header => root), not a buffer overflow. It could have happen in any language.

- C and C++ don't play in the same band anymore. Most security vulnerabilities affecting C generally do not affect C++ (no stack based string handling, no VLA, no void* everywhere, proper RAII, proper type safety)

And yes for developing a minimum-memory-footprint system daemon in 2021, I would use C++ or Rust but definitively not C.

Yes, note that I didn’t say this was a classic C vulnerability but that I’d expect to see more bugs of that class all other things being equal. C++ has been getting better but that doesn’t automatically remediate all of the code in the world and retrain every developer.

OMI may listen on the network (depending on what Azure feature is configuring it), but you will find that the most common azure feature pushing OMI does not configure it to listen on the network, which is Log Analytics.

Yeah, the discussion made it clear that this is a configurable problem. I think the puzzling part for me is that a new network service got so little review – after Microsoft’s decades trying to recover from bad calls in the 90s I’d have expected that to trigger more review.

The vuln is that API calls with no auth headers run as root.

You can avoid unwanted agents by avoiding cloud provider.

Bare metal ig.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact