Advisory: Time modification flaw in BSD securelevels on NetBSD and Linux The implementations of securelevels on NetBSD and Linux contain an integer overflow, allowing the protection of system time to be completely circumvented. Details ======= Product: NetBSD Linux Affected Versions: NetBSD-current: source prior to December 5, 2005 NetBSD 2.1 NetBSD 2.0.3 NetBSD 1.6.2 Linux vanilla kernel 2.6.15 and below Fixed Versions: NetBSD-current: December 5, 2005 NetBSD-3 branch: December 6, 2005 NetBSD-2.1 branch: December 6, 2005 NetBSD-2.0 branch: December 6, 2005 NetBSD-2 branch: December 6, 2005 NetBSD-1.6 branch: December 6, 2005 Vulnerability Type: System time modification Security-Risk: Medium Advisory-URL: http://www.redteam-pentesting.de/advisories/rt-sa-2005-16.txt Advisory-Status: public CVE: CVE-2005-4352 CVE-URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4352 Introduction ============ BSD-Securelevels try to harden the system by restricting certain functions. The manpage[1] states: "The kernel runs with five different levels of security. Any super-user process can raise the security level, but no process can lower it." When running a securelevel equal or higher than two kernel time changes are restricted. While it is possible to set the clock forward, it is not possible to turn it backwards. By setting the clock forward to the end of unixtime an integer overflow will be triggered and the clock will be reset. More Details ============ By setting the system time to the end of unixtime, it is possible to reset the system time to the lowest possible integer of unixtime. When the systemclock reaches "Tue Jan 19 03:14:08 UTC 2038", the 32-bit signed integer containing the time will overflow and the system time will be reset to "Fri Dec 13 20:45:52 UTC 1901". This is known as the Year 2038 Problem. The flaw is also present when running a securelevel of two or greater, allowing the restrictions on kernel time changes to be circumvented. Proof of Concept ================ # date 203801190414.07 Di 19 Jan 2038 04:14:07 CET # date Fr 13 Dez 1901 21:45:53 CET Workaround ========== No workaround is available. Fix === The problem has been fixed in all affected versions of NetBSD. No fix is available for the Linux implementation of securelevels. Security Risk ============= The security risk is to be considered medium. System time is crucial for the reliability and stability of a system. Time modification can cause denial of service and other major problems. For instance expired certificates can still be used. History ======= 2005-11-05 Problem discovered while testing a product of iPisec Ltd. 2005-11-29 Discussed the issue with iPisec management and technicians 2005-12-02 Contacted the maintainer of BSD-Securelevels on Linux 2005-12-02 Response from the maintainer of BSD-Securelevels on Linux he wants to do what *BSD will be doing 2005-12-04 Contacted NetBSD security 2005-12-05 Response from NetBSD security - problem has been fixed 2005-12-15 Forwarded the *BSD responses to the Linux maintainer 2006-01-05 No further response from the Linux maintainer 2006-01-09 Coordinated public release Reference ========= [1] http://www.freebsd.org/cgi/man.cgi?query=securelevel RedTeam ======= RedTeam offers interested business parties penetration tests to validate their security. Doing security research RedTeam likes to enhance the common knowledgebase in security related areas. More information about RedTeam can be found at http://www.redteam-pentesting.de. -- RedTeam Pentesting Tel.: +49-(0)241-963 1300 Dennewartstr. 25-27 Fax : +49-(0)241-963 1304 52068 Aachen http://www.redteam-pentesting.de