Skip to content
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

Printing server secret key in plain text in journalctl #149

Closed
the-magician opened this issue Jun 2, 2020 · 12 comments · Fixed by #150
Closed

Printing server secret key in plain text in journalctl #149

the-magician opened this issue Jun 2, 2020 · 12 comments · Fixed by #150

Comments

@the-magician
Copy link

In the example, we can see that server secret key is printed in plain text in journalctl logs. If an attacker is using man-in-the-middle attack and somehow gets these logs, he/she can decrypt and see all packets. User passwords will also be exposed by that.

@the-magician
Copy link
Author

We are printing this here:

_pam_log(LOG_DEBUG, "server[%lu] { addr=%s, key='%s' }", n, tac_ntop(tac_srv[n].addr->ai_addr),
as a debug log. Still printing secure key in plain text anywhere is a security vulnerability.

gollub added a commit to gollub/pam_tacplus that referenced this issue Jun 2, 2020
If journald for syslog the journal is going to store everything,
even DEBUG loglevel messages. Pre-journald this could be avoided.

Fix kravietz#149

Signed-off-by: Daniel Gollub <dgollub@att.com>
gollub added a commit to gollub/pam_tacplus that referenced this issue Jun 2, 2020
If journald for syslog is used, the journal is going to store everything,
even DEBUG loglevel messages. Pre-journald logging of system-wide DEBUG
loglevel could be avoided and is not affected in all cases.

With journald presence it's probably safe to no longer log sensitive
details at DEBUG level.

Fix kravietz#149

Signed-off-by: Daniel Gollub <dgollub@att.com>
@gollub
Copy link
Collaborator

gollub commented Jun 2, 2020

IIUC this affects "only" journald environments. Pre-journald are not affected, unless they store/log the DEBUG loglevel for this particular facility.

https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-18#section-10.1 ... this is not encryption, this is obfuscation :)

But yes, this might could be considered a security vulnerability, if the pam_tacplus module is used in a journald environment. Stock libtac users would be not affected, only pam_tacplus users.

@kravietz how was such things handled in the past? CVE?

@kravietz
Copy link
Owner

kravietz commented Jun 3, 2020

The secret is stored in the configuration file anyway, so if you've got access to the server and can see it in the logs, it's game over anyway. Alternatively, if you've got journald, and logs are forwarded to a remote server, and someone captures that - there's quite a lot of "ifs" here IMHO to make it an actual vulnerability but should be definitely fixed.

@erahn
Copy link

erahn commented Jun 3, 2020

Hello everyone,

First off, it's great that this was fixed so quickly. Thank you for that!

I think that regardless of the strength of the protocol and regardless of how the key is stored, logging secrets is generally considered a security issue. I think that users of this module would need a clear note that this was happening and they can make up their minds from there. A CVE is the traditional vehicle to deliver that message.

https://cwe.mitre.org/data/definitions/532.html shows examples of prior times where this was considered an issue and a CVE was opened.

@gollub
Copy link
Collaborator

gollub commented Jun 3, 2020

@kravietz , would now be a good time to release 1.5.2?

I could drive the CVE assignment / disclosure on oss-security, if you like?

@kravietz
Copy link
Owner

kravietz commented Jun 4, 2020

@gollub This is a very good point, if you have capacity the do CVE then sure, go for it and we can bump the version to 1.5.3 with the new CVE info so it's properly picked up by downstream distros.

@gollub
Copy link
Collaborator

gollub commented Jun 4, 2020

Could you release 1.5.2/3? The MITRE form asks for a fixed version.

@kravietz kravietz reopened this Jun 4, 2020
@kravietz
Copy link
Owner

kravietz commented Jun 4, 2020

Done 1.5.3. Waiting for Travis and Sr.ht builds to complete, but should be fine.

deastoe added a commit to deastoe/pam_tacplus that referenced this issue Jun 5, 2020
Following kravietz#149 remove the debug option from the example PAM configs,
to avoid accidental use by copy-paste.
@the-magician
Copy link
Author

@gollub Is CVE for this filed yet? If it is filed, can you please provide the CVE ID here. If not and if it's not an effort, can you please in the CVE for originally finding it as "Adarsh Pandey from Arista Networks"?

@carnil
Copy link

carnil commented Jun 7, 2020

CVE-2020-13881 was assigned for this issue.

@gollub
Copy link
Collaborator

gollub commented Jun 8, 2020

@the-magician , yes I filed the CVE request Friday morning (CET), MITRE assigned CVE-2020-13881 Saturday evening (CET).

With respect to the credit and CVE/MITRE: https://cve.mitre.org/about/faqs.html#does_cve_entry_credit_discoverer

But I referred you as the original reporter in the oss-security mail, which I just send.

@gollub gollub closed this as completed Jun 8, 2020
@gollub
Copy link
Collaborator

gollub commented Jun 8, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants