Critical flaws have been found in two open-source applications: Concurrent Versions System (CVS), a popular open-source application within which many developers store code, and Subversion, which was built to be a compelling replacement for CVS in the open-source community.
Stefan Esser, the security researcher who discovered the flaws, released advisories Wednesday recommending that the applications be updated immediately. Esser is the chief security and technology officer at e-Matters, a German technology company.
The first flaw pertains to CVS releases up to 1.11.15 and CVS feature releases up to 1.12.7. Both contain a flaw that occurs when deciding whether a CVS entry line should get a flag reading modified or unchanged.
When remote users send entry lines to the server, an additional byte is allocated so as to have ample space for later flagging of the entry. Users are then allowed to insert "M" or "=" characters into the middle of strings, which would result in whats called a heap overflow. The flaw could allow a remote attacker to execute arbitrary code on the CVS server.
According to Essers advisory, CVS developers were notified of the flaw earlier this month. Derek Robert Price replied that the flaw had already been fixed.
According to the disclosure timeline in Essers advisory, important code repositories were notified before the flaws were made public Wednesday.
The second flaw, in Subversion—which is released under an Apache/BSD-style open-source license—is easy to exploit, according to Essers advisory.
"Exploiting this vulnerability on not heavily protected servers is trivial even for beginners," Esser wrote. "Even ProPolice users arent safe because overwriting function arguments allows some fancy exploits."
(ProPolice was developed by IBM and protects against "stack-smashing" attacks, a common way to break program security.)
Subversion versions up to 1.0.2 are vulnerable to the flaw, which is a date-parsing vulnerability that can be exploited to allow remote code execution on Subversion servers and thereby compromise repositories.
The flaw resides in an unsafe call to sscanf() in a Subversion date-parsing function. When Subversion attempts to convert a string into an apr_time_t, it falls back to sscanf() to decode old-styled date strings, according to Essers advisory. That function is exposed to external attack through a DAV2 REPORT query or a get-dated-rev svn-protocol command.
The first way is "somewhat harder" to exploit, Esser wrote, whereas the second is a standard stack overflow with the exception that white space and the "\0" character are forbidden.
Editors Note: This story was updated to correctly identify the nature of the two applications.