
Certificate Transparency Log Compromised via Salt Vulnerability - panarky
https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/aKNbZuJzwfM
======
tialaramex
This doesn't impact on the security promises CT gives us in practice because
it's just one log and all extant CT policies require multiple logs.

However some of the unfinished work on CT means that we're more vulnerable
here than would be ideal.

For example: An adversary who does have the SCT private key can make any SCT.
So they can make one which says this log saw a certificate last month, before
their compromise, because that's just a date change and they get to pick what
is signed. This claim would be untrue, but nobody would automatically notice
that.

In theory the complete CT system could detect this SCT - at least
probabilistically - because clients which are shown the SCT could periodically
check whether a log consistent with that SCT actually exists and report
mysterious SCTs that don't match. But that isn't yet built, a Chrome which is
shown an SCT from a trusted log promising the certificate was logged last
month just takes that as gospel truth.

Now for Google this is pretty satisfactory because their CT policy requires
that you use their (Google's) logs. But for a third party like Apple it's a
bit less comfortable. If the Google logs suffered a security breach, Apple has
no reassurance that they would find there was a problem short of Google
voluntarily letting them know.

------
jrockway
I came at this article from the angle that "salt" referred to the
cryptographic type, but it's actually some configuration management framework
thingie. So there is not a cryptographic vulnerability in CT, but rather one
particular log was compromised because of the software they use to run their
servers. Very confusing.

~~~
toomuchtodo
SaltStack Wikipedia entry for the curious:
[https://en.wikipedia.org/wiki/Salt_(software)](https://en.wikipedia.org/wiki/Salt_\(software\))

------
geerlingguy
I just received a notice that many CentOS 6 systems managed by RamNode were
also compromised; it seems like they were customer instances, but in that
case, the malicious parties installed BTC miners on all the servers, and one
of my tiny VPSes was collateral damage for a couple hours, as they worked to
contain the situation.

------
afrcnc
More here: [https://www.zdnet.com/article/ghost-blogging-platform-
server...](https://www.zdnet.com/article/ghost-blogging-platform-servers-
hacked-and-infected-with-crypto-miner/)

~~~
jlgaddis
Original article/warning from Threatpost: [https://threatpost.com/salt-bugs-
full-rce-root-cloud-servers...](https://threatpost.com/salt-bugs-full-rce-
root-cloud-servers/155383/)

------
ddevault
I published this article a couple of weeks ago:

[https://sourcehut.org/blog/2020-04-20-prioritizing-
simplitit...](https://sourcehut.org/blog/2020-04-20-prioritizing-simplitity/)

Dozens of people wrote to me, aghast at the idea that I provision servers
manually, wondering how I could refuse to use the rube goldberg machines that
define the modern "cloud-scale" computing trends. It looks like it didn't take
long for my approach to be validated.

Salt is complicated as hell. k8s, Docker, Ansible, they're all the same.
Complicated systems break more often and more severely than simple systems.
It's a simple fact, and I hope that our industry gets over its collective
devops fetish sooner rather than later.

~~~
tptacek
No, Salt is distinctive: it uses resident agents, unlike other tools;
infamously, they managed to implement e=1 RSA in their transport protocol. You
cannot reasonably extrapolate from Salt to Terraform or Ansible.

~~~
tialaramex
I feel like the resident agent thing is the wrong focus.

Goofing RSA is a more troubling sign, because it means there probably isn't
anybody who understands how this stuff works in the room where plans to use it
are made, and that means there will be security bugs forever.

Presumably other people don't agree with me or else there wouldn't be
important stuff running on Salt?

~~~
tptacek
I don't even know if they still use the transport protocol they came up with.
I remember more clearly the Red Hat security guy claiming, on the same Github
issue thread, that e=3 RSA was dangerous because of GPUs, which is almost an
equally fucky thing to say.

The agent thing, though, would squick me out almost no matter which team
implemented it.

