Hacker News Reader

Comment by shockinglytrue | Hacker News Reader

Attributing this just to Salt is deeply unfair. Ansible has had many similar issues over time, also homebrew encryption etc.

View on HN

Ansible doesn't have a server to expose, let alone publicly. It could be just as bad and still be safer. (So ex. Puppet would also make me nervous) Now, I suspect that Ansible is also in a better position because it's mostly SSH-based, but the architecture also inherently makes it harder to have this level of problem.

Serverless isn't a cure all, Ansible has had numerous code exec bugs due to e.g. interpreting strings coming back from remote machines or third party APIs as templates.

Some of these bugs aren't even that old

Both Ansible and Salt are underengineered, but highly convenient.

> Ansible has had numerous code exec bugs due to e.g. interpreting strings coming back from remote machines or third party APIs as templates.

Sure, and that is bad, but the exposure is still way smaller. Let's say that Ansible has a bug that allows code execution on my machine by any target server or API, and Salt has a bug that allows code execution on the master server. In that case, the salt server will be owned by script kiddies within hours and the only way to stop it is me killing it or restricting access. But at the same time, the Ansible bug can't be passively exploited without me running it, and can only be exploited by my own servers or vendors when I decide to interact with them. I don't actually expect AWS/DO/whoever to attack me, and my own servers could be compromised but that's still a much less likely jumping attack.

What about AWX/Tower? It offers both a GUI and REST interface to the playbooks.

Yep, anything that makes it a server process that listens for connections definitely takes you into the same category. Likewise, running puppet or salt in the local-only mode removes the issue from them.

And this attack payload would have hit ansible servers just as hard. Looking at the payload script if the SSH keys were not password protected it would have logged into the servers https://github.com/Aldenar/salt-malware-sources/blob/master/...

once it had root access it would have hit anything hard. But it wouldn't have been able to get root access in the first place because ansible doesn't have a port listening on the internet

Ansible is relying on SSH for security and does not use any homebrew crypto or protocols by default.

ansible-vault is homebrew crypto

it uses the standard cryptography or pycrypto backends as everything else

I don't understand this claim. ansible-vault uses AES256 which is anything but homebrew.

Salt uses AES too. The problem is it puts together standard primitives in homebrew protocols. Cryptographic protocol design is as likely to mess your system up as cryptographic primitive design.

This is why like me, you're not a cryptographer. AES256 is a cipher, its one component of a cryptosystem. Analysing cryptosystems is a complex area that does not involve vetting software for buzzwords.

I can take AES256 and make it output the image here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...

That's not supposed to happen. The part where homebrew diverges from cryptography is that the former involves engineers like us connecting buzzwords together to produce images like the Wikipedia article, the latter involves complex math and rigorous peer review.

I think you're just trolling

> homebrew crypto

AES-256?

https://linux.die.net/man/3/ansible.fireball

It definitely has them however.

You can use salt over SSH, but it is not the default.

Reply on news.ycombinator.com