-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pillar matching on mine.get can be used to discover pillar info #7197
Comments
I think it should work for pillar. Thanks for the report, we'll look into it. |
@Mrten I'm not able to replicate this against git, can you test against an up-to-date checkout? |
Not easily, no. I'm on the ubuntu PPA, I tried the salt-daily PPA but the version number there is 0.16.0 and apt-get won't let me downgrade. |
OK, this helped:
Then I do indeed get the right results. |
Erm, isn't it a security problem? Because this works as well:
So you can infer pillar data from minions this way. Pillars are supposed to be secret, right? This leaks pillar-data to other minions. |
Yeah, you can't exactly ask for the data and get it back, but you can keep asking and start to get a picture of other hosts' pillar data. We'll discuss this internally, and try to come up with a solution. |
Generally, pillar things that need to remain secret are password hashes, keys, and the like. You're never going to be able to guess those values to infer pillar on other minions. That said, it would probably be fairly simple to make it configurable whether mine allowed pillar targeting or not. Easy fix, should please everyone. =) |
Did we open a new issue for the pillar targeting? Looks like this issue can be closed, but we should open a new issue for the pillar targeting before we forget. |
I do not think we have opened a new issue, no. |
Can you do regexp or glob pillar matching? Because if you can, you can iterate over all characters à la BEAST (or was it CRIME) and recover ssl keys. (for the uninitiated: try a_, b_, c_..., z_, then if d is a hit: da_, db_, dc_, dd_, etc) |
Good point, I don't know if it supports globs or not. I want to say "no" but I'm not sure. Could you test that? I don't have the mine set up on my test machine. |
They do, sir, they do.
I don't know the syntax for deeper nested pillar matching, so I did not get that to work. |
Yep, in this case we need to definitely remove globbing support for the mine, and then additionally make pillar matching configurable in the first place. Thanks for your good detective work here. |
I'm going to repurpose this bug for the pillar matching problems, rather than create a new one. Renaming and re-labeling. |
So, since 0.17 is out, is this now CVE-worthy? This kinda prevents me from putting secret data in the pillar. |
This was fixed right? I thought @basepi got it.... |
Nope, it's one of my many open tabs reminding me "hey, this needs to be fixed!" |
Sorry this one took so long for such a simple solution. Fix will be in 0.17.1. |
EDITED by @basepi: Repurposing this bug report for the potential pillar security implications of being able to match on pillar, specifically with globbing.
I'm thinking these two calls should've reported the same number (well not really because the mine.get call has two extra lines of output but 34 is too different)
The latter returns all the minions, where it should only return the minions where the
location
pillar is1
, right?This works for grains, and the manual says it should work for pillars as well.
Mine config:
The text was updated successfully, but these errors were encountered: