View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000803 | Main CAcert Website | misc | public | 2010-01-05 00:38 | 2013-01-15 14:29 |
Reporter | NEOatNHNG | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | open | ||
Fixed in Version | 2010 Q2 | ||||
Summary | 0000803: Security Vulnerability: DNS servers have AXFR zone transfer enabled | ||||
Description | The following vulnerability was reported via support@cacert.org: Hi, we discovered a severe security leakage in CAcert's DNS zone. An attacker might gather relevant information about the hosts inside the zone. The real severity depends on the internal structures. The nameserver dns4.go-now.at allows public AXFR zone transfer of the entire dataset. We recommend disabling AXFR on the nameserver and verify security on other DNS hosts accordingly. Regards, Felix Falk, Dominik George | ||||
Tags | No tags attached. | ||||
Reviewed by | |||||
Test Instructions | |||||
|
From e-mail Philip Guehring 05.01.2010 09:48: CAcert does not have any secret machines in this DNS zone, so this is not an issue. From e-mail Wytze van der Raay 05.01.2010 10:59: I agree with Philipp, the information in the cacert.org zone is not secret. We may even end up maintaining the zone file in a publically visible revision control system. |
|
I agree with the two commenters, but as AXFR is "an issue" by design, I would still recommend to close it down. As far as security is concerned, no potentially dangerous "feature" should be enabled on any related system, no matter whether it is an actual security leak or not. It might become in the future. |
|
Natureshadow, could you please elaborate why AXFR would be "an issue" (I suppose you mean: potentially dangerous feature) by design? In particular in a situation where we have no intent at all to treat the contents of the zone file as a secret? On the other hand, we are moving towards a new DNS infrastructure setup, and in that setup zone transfers will be restricted and protected by TSIG. In the current setup we have been unable to do this. So if you like, we can keep this issue open until the new setup is in place. But I would recommend to lower the severity -- it is definitely not "major" given all comments above. |
|
I totally agree it is not major. AXFR may not be an issue, but the way some providers tend to use it is. The rest boils down to what I already mentioned, disable all protocols that are not needed if you are running critical services. |
|
Why argue about this? It would take just a few minutes to change the configuration and restrain AXFR to the slaves. I bet you took more time reading this entry and replying. Jeesh! |
|
As far as I know zone transfers have been disabled on all nameservers some time ago. Have just tested it for cacert.org on all six NS. The official nameservers for cacert.net have also axfr disabled. One of the old nameservers leaks an old zone, will notify the dnsadmin. |
|
It would be good for a mod to change the status then. |
|
You are absolutely right. Maybe someone with sufficient permissions will do that. I don't have them :-( |
|
Confirmed that zone transfers have been turned off on old nameservers. |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-01-05 00:38 | NEOatNHNG | New Issue | |
2010-01-05 10:01 | wytze | Note Added: 0001544 | |
2010-01-05 11:46 | Natureshadow | Note Added: 0001545 | |
2010-01-05 12:02 | wytze | Note Added: 0001546 | |
2010-01-05 12:05 | Natureshadow | Note Added: 0001547 | |
2010-04-18 22:32 | aderouineau | Note Added: 0001575 | |
2010-04-23 17:03 | Andreas Baess | Note Added: 0001577 | |
2010-04-23 17:16 | aderouineau | Note Added: 0001578 | |
2010-04-23 17:33 | Andreas Baess | Note Added: 0001579 | |
2010-05-01 14:56 | wytze | Note Added: 0001580 | |
2010-05-01 14:57 | wytze | Status | new => closed |
2013-01-15 14:29 | Werner Dworak | Fixed in Version | => 2010 Q2 |