var-200010-0031
Vulnerability from variot
Checkpoint Firewall-1 with the RSH/REXEC setting enabled allows remote attackers to bypass access restrictions and connect to a RSH/REXEC client via malformed connection requests. Check Point Firewall-1 is vulnerable to certain unauthorized connections, caused by sending a specially formatted RSH/REXEC connection request from an external RSH/REXEC server to an internal (protected) RSH/REXEC client. This can only be done if the FireWall-1 administrator specifically enabled RSH/REXEC with stderr-port support in the Properties window. The problem has to do with the pending table used to store state information for when rsh connections are initialized with stderr-port support. The pending table is a Firewall-1 internal memory structure used to hold temporary information about the state of a new connection before it is added to the "connection table", where state information (remote, destination ip addresses and ports, protocol type, etc) for permitted connections is stored. Because of the way data from the pending table is interpreted and certain conditions met by the nature of Firewall-1's handling of the rsh/rexec stderr-port (the acceptance of an additional syn packet), it is possible to collide an entry in the pending table before it is written to the connection table as the stderr-port connection. When stderr connections for rsh/rexec are permitted, information from the first data packet of an rsh connection is stored in the pending table so the firewall can anticipate the stderr syn. The stderr port is extracted from the tcp data segment of this initial data packet. In addition, the source, destination ip addresses and ports are stored, as well as a magic number and the IP protocol code. Firewall-1 then waits for a syn for the stderr connection. When one is recieved, another entry is made into the pending table, only the sequence number + 1 is stored in the place where the IP protocol number would go. If a malicious SYN is crafted with a sequence number of 5 and sent to the Firewall-1 that is expecting a rsh/rexec stderr syn, the sequence number will be stored as 6 in the place where the protocol code (which happened to be 6, for TCP) is for the previous entry. The firewall then checks this and allows this connection to be established regardless of what the port is in the malicious syn. It is then possible for an attacker to communicate with an "rsh client' on an arbitrary port behind the firewall. The impact is that if rsh/rexec stderr-port is permitted, back-connections through the firewall can be established. Checkpoint Firewall-1 with valid RSH/REXEC settings has a vulnerability
Show details on source website{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "configurations": { "@id": "https://www.variotdbs.pl/ref/configurations" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "iot_taxonomy": { "@id": "https://www.variotdbs.pl/ref/iot_taxonomy/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-200010-0031", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "firewall-1", "scope": "eq", "trust": 1.6, "vendor": "checkpoint", "version": "4.0" }, { "model": "firewall-1", "scope": "eq", "trust": 1.6, "vendor": "checkpoint", "version": "3.0" }, { "model": "firewall-1", "scope": "eq", "trust": 1.6, "vendor": "checkpoint", "version": "4.1" }, { "model": "point software firewall-1", "scope": "eq", "trust": 0.3, "vendor": "check", "version": "4.1" }, { "model": "point software firewall-1", "scope": "eq", "trust": 0.3, "vendor": "check", "version": "4.0" }, { "model": "point software firewall-1", "scope": "eq", "trust": 0.3, "vendor": "check", "version": "3.0" } ], "sources": [ { "db": "BID", "id": "1534" }, { "db": "CNNVD", "id": "CNNVD-200010-094" }, { "db": "NVD", "id": "CVE-2000-0779" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "The following individuals discovered this vulnerability and discussed it at Black Hat 2000.\nThomas Lopatic and John McDonald, TUV data protect GmbH\nDug Song, University of Michigan CITI", "sources": [ { "db": "BID", "id": "1534" } ], "trust": 0.3 }, "cve": "CVE-2000-0779", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "LOW", "accessVector": "NETWORK", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "PARTIAL", "baseScore": 7.5, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 10.0, "id": "CVE-2000-0779", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "HIGH", "trust": 1.0, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0" }, { "accessComplexity": "LOW", "accessVector": "NETWORK", "authentication": "NONE", "author": "VULHUB", "availabilityImpact": "PARTIAL", "baseScore": 7.5, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 10.0, "id": "VHN-2356", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "HIGH", "trust": 0.1, "vectorString": "AV:N/AC:L/AU:N/C:P/I:P/A:P", "version": "2.0" } ], "cvssV3": [], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2000-0779", "trust": 1.0, "value": "HIGH" }, { "author": "CNNVD", "id": "CNNVD-200010-094", "trust": 0.6, "value": "HIGH" }, { "author": "VULHUB", "id": "VHN-2356", "trust": 0.1, "value": "HIGH" } ] } ], "sources": [ { "db": "VULHUB", "id": "VHN-2356" }, { "db": "CNNVD", "id": "CNNVD-200010-094" }, { "db": "NVD", "id": "CVE-2000-0779" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Checkpoint Firewall-1 with the RSH/REXEC setting enabled allows remote attackers to bypass access restrictions and connect to a RSH/REXEC client via malformed connection requests. Check Point Firewall-1 is vulnerable to certain unauthorized connections, caused by sending a specially formatted RSH/REXEC connection request from an external RSH/REXEC server to an internal (protected) RSH/REXEC client. This can only be done if the FireWall-1 administrator specifically enabled RSH/REXEC with stderr-port support in the Properties window. \nThe problem has to do with the pending table used to store state information for when rsh connections are initialized with stderr-port support. The pending table is a Firewall-1 internal memory structure used to hold temporary information about the state of a new connection before it is added to the \"connection table\", where state information (remote, destination ip addresses and ports, protocol type, etc) for permitted connections is stored. \nBecause of the way data from the pending table is interpreted and certain conditions met by the nature of Firewall-1\u0027s handling of the rsh/rexec stderr-port (the acceptance of an additional syn packet), it is possible to collide an entry in the pending table before it is written to the connection table as the stderr-port connection. When stderr connections for rsh/rexec are permitted, information from the first data packet of an rsh connection is stored in the pending table so the firewall can anticipate the stderr syn. The stderr port is extracted from the tcp data segment of this initial data packet. In addition, the source, destination ip addresses and ports are stored, as well as a magic number and the IP protocol code. Firewall-1 then waits for a syn for the stderr connection. When one is recieved, another entry is made into the pending table, only the sequence number + 1 is stored in the place where the IP protocol number would go. If a malicious SYN is crafted with a sequence number of 5 and sent to the Firewall-1 that is expecting a rsh/rexec stderr syn, the sequence number will be stored as 6 in the place where the protocol code (which happened to be 6, for TCP) is for the previous entry. The firewall then checks this and allows this connection to be established regardless of what the port is in the malicious syn. It is then possible for an attacker to communicate with an \"rsh client\u0027 on an arbitrary port behind the firewall. \nThe impact is that if rsh/rexec stderr-port is permitted, back-connections through the firewall can be established. Checkpoint Firewall-1 with valid RSH/REXEC settings has a vulnerability", "sources": [ { "db": "NVD", "id": "CVE-2000-0779" }, { "db": "BID", "id": "1534" }, { "db": "VULHUB", "id": "VHN-2356" } ], "trust": 1.26 }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "BID", "id": "1534", "trust": 2.0 }, { "db": "OSVDB", "id": "1487", "trust": 1.7 }, { "db": "NVD", "id": "CVE-2000-0779", "trust": 1.7 }, { "db": "CNNVD", "id": "CNNVD-200010-094", "trust": 0.6 }, { "db": "VULHUB", "id": "VHN-2356", "trust": 0.1 } ], "sources": [ { "db": "VULHUB", "id": "VHN-2356" }, { "db": "BID", "id": "1534" }, { "db": "CNNVD", "id": "CNNVD-200010-094" }, { "db": "NVD", "id": "CVE-2000-0779" } ] }, "id": "VAR-200010-0031", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VULHUB", "id": "VHN-2356" } ], "trust": 0.01 }, "last_update_date": "2024-08-14T15:25:52.204000Z", "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "NVD-CWE-Other", "trust": 1.0 } ], "sources": [ { "db": "NVD", "id": "CVE-2000-0779" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 1.7, "url": "http://www.securityfocus.com/bid/1534" }, { "trust": 1.7, "url": "http://www.checkpoint.com/techsupport/alerts/list_vun.html#improper_stderr" }, { "trust": 1.7, "url": "http://www.osvdb.org/1487" }, { "trust": 0.3, "url": "http://www.monkey.org/~dugsong/talks/blackhat.pdf" }, { "trust": 0.3, "url": "http://www.checkpoint.com/techsupport/alerts/list_vun.html" } ], "sources": [ { "db": "VULHUB", "id": "VHN-2356" }, { "db": "BID", "id": "1534" }, { "db": "CNNVD", "id": "CNNVD-200010-094" }, { "db": "NVD", "id": "CVE-2000-0779" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULHUB", "id": "VHN-2356" }, { "db": "BID", "id": "1534" }, { "db": "CNNVD", "id": "CNNVD-200010-094" }, { "db": "NVD", "id": "CVE-2000-0779" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2000-10-20T00:00:00", "db": "VULHUB", "id": "VHN-2356" }, { "date": "2000-08-02T00:00:00", "db": "BID", "id": "1534" }, { "date": "2000-10-20T00:00:00", "db": "CNNVD", "id": "CNNVD-200010-094" }, { "date": "2000-10-20T04:00:00", "db": "NVD", "id": "CVE-2000-0779" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2008-09-10T00:00:00", "db": "VULHUB", "id": "VHN-2356" }, { "date": "2000-08-02T00:00:00", "db": "BID", "id": "1534" }, { "date": "2006-01-04T00:00:00", "db": "CNNVD", "id": "CNNVD-200010-094" }, { "date": "2008-09-10T19:05:49.897000", "db": "NVD", "id": "CVE-2000-0779" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "remote", "sources": [ { "db": "CNNVD", "id": "CNNVD-200010-094" } ], "trust": 0.6 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Checkpoint Firewall-1 Vulnerability", "sources": [ { "db": "CNNVD", "id": "CNNVD-200010-094" } ], "trust": 0.6 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "unknown", "sources": [ { "db": "CNNVD", "id": "CNNVD-200010-094" } ], "trust": 0.6 } }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.