Time modification flaw in BSD securelevels on NetBSD and Linux Jan 09 2006 12:28PM
RedTeam Pentesting (release redteam-pentesting de)
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ8JW9tG/HXWsgFSuAQIwbAf/eTPZZcYMw0lI6KryfrVJzOtLU5BAKJBC
s42no+ZdYo9lSFjfzePEJVy1YUSSAXsJEs1SOPV8NNbfmEeQUnBm0/jqo0id3GEd
F6x5yW9i2U1Hs1OCQYxZq5tQhKwc/RjH9KhTsxhxSUJYPO5GyO2uiRUkzw2mBzOB
CnV8nJpXLXOgaYb704y00J5geJfqsyx2sQGLIndpc7YOtCuwckQRmDnY7NgC0FSa
G2CS+LVR5XJAomX8s141Sx6qmZHCHX9T9pMZ4wezVegOpFuPbZuYkLkHInf0eyEG
0iFeVCIkhjF80nVZpFojFneqWxY4Tt1AzSBnov6FsEl9l8EFakqB0g==
=v785
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus