Description of problem: By default, frr creates empty configuration files, however unfortunately with too wide permissions: As per http://docs.frrouting.org/en/latest/bgp.html, /etc/frr/bgpd.conf is also meant to contain the BGP password for peerings/sessions, thus proper default permissions should be applied by frr when even creating this file for administrator convenience. Otherwise information leaks are eased. Version-Release number of selected component (if applicable): frr-7.0-5.el8.x86_64 How reproducible: See above and below. Steps to Reproduce: 1. dnf install frr 2. sed -e 's/^zebra=no/zebra=yes/' -e 's/^bgpd=no/bgpd=yes/' -i /etc/frr/daemons 3. systemctl start frr.service 4. ls -l /etc/frr/bgpd.conf -rw-r--r--. 1 frr frr 0 May 4 01:07 /etc/frr/bgpd.conf 5. ls -ld /etc/frr/ drwxr-xr-x. 2 frr frr 4096 May 4 01:07 /etc/frr/ Actual results: World-readable /etc/frr/bgpd.conf by default. Expected results: /etc/frr/bgpd.conf should be maybe 640 by default. Additional info: I did not investigate whether this is an upstream or a downstream issue, given frr.service seems to be built on an old initscript (/usr/lib/frr/frr) rather being a modern systemd unit.
As per https://github.com/FRRouting/frr/blob/master/tools/frr.in#L100 this seems to be a possible frr vulnerability on upstream side rather a downstream mistake; please assign a CVE number.
Given the Red Hat Product Security team did not really care about this report, even after contacting secalert explicitly, I got in touch with upstream's security contact, which lead to https://github.com/FRRouting/frr/pull/6383 which will be also backported to upstream stable branches.
Submitted CVE Request 892850 for CVE ID directly at MITRE.
Created frr tracking bugs for this issue: Affects: fedora-all [bug 1848993]
Upstream commit for this issue: https://github.com/FRRouting/frr/commit/5c9063771195bb51a8cc1c64f9924e53a0602817
Hello Robert, We are now handling this as a security issue. Thank you very much for reporting this earlier. May we acknowledge you as the reporter on our cve pages? If yes, how would you like to be called? Best regards. Marian
Hello Marian, yes, you may acknowledge me as the reporter, using just "Robert Scheck" is fine.
Acknowledgments: Name: Robert Scheck
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-12831
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4619 https://access.redhat.com/errata/RHSA-2020:4619