| Summary: | [cloud-init] [Security] Root password should be always hashed if written in plaintext | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Jiri Belka <jbelka> |
| Component: | General | Assignee: | Nobody <nobody> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | bugs, fdeutsch, lpeer, mgoldboi, michal.skrivanek, pnovotny, rbarry, Rhev-m-bugs, srevivo |
| Target Milestone: | --- | Flags: | michal.skrivanek:
ovirt-4.3?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-21 00:05:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jiri Belka
2013-11-29 12:10:54 UTC
Idea: ideally cloud-init should be able to read virtual channel and get its data from there (thus it would need code for this new datasource). RHEVM part would reply to data request on this virtual channel. Setting urgent priority until analysed well, not really urgent. The cloud-init cdrom is not attached during regular runs so it should not be exposed at all. The problem with hashing is that as per vfeenstr it's not really much safer as the hashing is too easy to decode I don't see we can do much other than making user aware this is the behavior(and fix those bugs you mention) Two comments first: * there was a bug in RHEVM which was attaching cloud-init image during every VM run * if you run with Run Once, then cloud-init image is attached, even it is not mounted. But a user can mounted from GNOME. And about hashing... That's nonsense, RHEL uses salted sha512 hashes. If you know how to easy "decode" such password, please share your know-how with world IT community, you would receive big publicity :-) Dictionary attack is off-topic. (In reply to Jiri Belka from comment #4) > And about hashing... That's nonsense, RHEL uses salted sha512 hashes. If you > know how to easy "decode" such password, please share your know-how with > world IT community, you would receive big publicity :-) Dictionary attack is > off-topic. This is actually nothing new. The point is that you usually have not so easy access to the store, and well a dictionary attach is not really off-topic, that's simply part of the problem: # passwd: The hash -- not the password itself -- of the password you want # to use for this user. You can generate a safe hash via: # mkpasswd --method=SHA-512 --rounds=4096 # (the above command would create from stdin an SHA-512 password hash # with 4096 salt rounds) # # Please note: while the use of a hashed password is better than # plain text, the use of this feature is not ideal. Also, # using a high number of salting rounds will help, but it should # not be relied upon. # # To highlight this risk, running John the Ripper against the # example hash above, with a readily available wordlist, revealed # the true password in 12 seconds on a i7-2620QM. # # In other words, this feature is a potential security risk and is # provided for your convenience only. If you do not fully trust the # medium over which your cloud-config will be transmitted, then you # should use SSH authentication only. Source: http://cloudinit.readthedocs.org/en/latest/topics/examples.html Jiri, so the image itself is reasonably secured now, what else do you want to do? In the light of the last comment. Comment #4 says one can attach CI image as normal cdrom on GNOME without any trouble. Enforce hashed passwords, point. If one would accept there's always possibility to crack hashed passwords and do nothing at least to make things harder, then tell me - why do we have /etc/shadow ? Because it's another mitigation protection. But I think to attach CI data as cdrom is stupid anyway. I think the best way would be via virt-channel, so any user by default could not request CI data. Current functionality is wrong by design. it's not really safer as you can intercept the channel the same way as you can mount a CD. It makes it a bit more difficult to do, though. I'd suggest not to fix this at the moment as the feature is still quite fresh and the added benefit of easier debugging/troubleshooting with CD is quite worth it this bug won't fit into 3.5 release and is being deferred to a later release. If you deeply care about this bug and deserves to be re-evaluated please let me know This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset. Please set the correct milestone or add the flag. Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. Jiri, can you please summaries the current status and expected behavior? Original idea what to hash password by engine before sending them to host and having them as hashed in cloud-init payload. I personally have no use case and I don't know any customer backing this idea. The idea was just based on fact, that any ordinary user can attach cdrom in Linux guest with desktop UI installed. Feel free to close this BZ. pushed out due to capacity reasons The bug was not addressed in time for 4.1. Postponing to 4.2 Upstream is looking into supporting setting hashed password for already defined users: https://bugs.launchpad.net/cloud-init/+bug/1570325 Setting hashed password is/was only supported if the user didn't exist previously Closing since this has been deferred over and over again. If users don't want users to be able to mount random ISOs to view the contents, this can be nailed down using permissions |