Vulnerabilites related to citect - citectfacilities
Vulnerability from fkie_nvd
Vendor | Product | Version | |
---|---|---|---|
citect | citectfacilities | 7 | |
citect | citectscada | 6 | |
citect | citectscada | 7 |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:citect:citectfacilities:7:*:*:*:*:*:*:*", "matchCriteriaId": "A1AA63D7-B3D6-40CD-B871-B8BEC70D0EC7", "vulnerable": true }, { "criteria": "cpe:2.3:a:citect:citectscada:6:*:*:*:*:*:*:*", "matchCriteriaId": "5AB59393-7CF9-4AAF-B5D9-4D57198DDBCE", "vulnerable": true }, { "criteria": "cpe:2.3:a:citect:citectscada:7:*:*:*:*:*:*:*", "matchCriteriaId": "0239F180-38AC-4ECF-B17E-AC7DEA42EB26", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "Stack-based buffer overflow in the ODBC server service in Citect CitectSCADA 6 and 7, and CitectFacilities 7, allows remote attackers to execute arbitrary code via a long string in the second application packet in a TCP session on port 20222." }, { "lang": "es", "value": "Desbordamiento de b\u00fafer basado en pila en el servicio del servidor ODBC en CitectSCADA 6 y 7 y CitectFacilities 7, permite a atacantes remotos ejecutar c\u00f3digo arbitrario mediante una cadena larga en el segundo paquete de aplicaci\u00f3n en una sesi\u00f3n TCP en el puerto 20222." } ], "evaluatorComment": "The vulnerability found in CitectSCADA could allow a remote un-authenticated attacker to force an abnormal termination of the vulnerable software (Denial of Service) or to execute arbitrary code on vulnerable systems to gain complete control of the software. The CitectSCADA and CitectFacilities applications include ODBC server capabilities to provide remote SQL access to a relational database. For that purpose, an ODBC Server component is used to service requests from clients on TCP/IP networks. Requests are serviced over a TCP high-port in which the application layer protocol reads an initial packet that specifies the length of data and then a second packet of data, of the same length is then read. Once the data is read from the network, it is then copied to an internal buffer of fixed size allocated in the stack without previously verifying that the buffer is big enough to store all the read data.\r\n\r\nThe vulnerability is related to a lack of a proper length-checking on data read from the network. A specially crafted combination of length and data packets could be used to exploit the vulnerability allowing an un-authenticated attacker to execute arbitrary code on vulnerable systems.\r\n\r\nThe bug is a texbook example of classic simple stack-based buffer overflow vulnerabilities of the 1990s that can be exploited by overwriting the return address of the currently running thread.\r\n\r\nFixes and Workarounds:\r\n\r\nUser organizations should deploy the vendor patch, which is available upon request at http://www.citect.com/ or disable the vulnerable service (ODBC server) if it is not needed in their particular installation.", "evaluatorImpact": "The access complexity for this vulnerability is set at High due to the fact that exploiting this vulnerability requires the SCADA system to be connected to the internet and the client needs to be using ODBC technology. SCADA systems are not typically installed to connect to the internet for security purposes. While the vendor acknowledges that this vulnerability exists and will provide a patch upon request, they point out that this can be easily mitigated by ensuring SCADA systems (not limited to Citect products) are not connected to the internet.\r\n", "evaluatorSolution": "Citect will provide a patch upon request to mitigate this vulnerability. Please see the following press release for more information:\r\n\r\nhttp://www.citect.com/documents/news_and_media/pr-citect-address-security.pdf\r\n\r\nFor further information on properly securing SCADA systems, please see the following whitepaper published by Citect:\r\n\r\nhttp://www.citect.com/documents/whitepapers/scada-security-whitepaper.pdf", "id": "CVE-2008-2639", "lastModified": "2025-04-09T00:30:58.490", "metrics": { "cvssMetricV2": [ { "acInsufInfo": false, "baseSeverity": "HIGH", "cvssData": { "accessComplexity": "HIGH", "accessVector": "NETWORK", "authentication": "NONE", "availabilityImpact": "COMPLETE", "baseScore": 7.6, "confidentialityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "vectorString": "AV:N/AC:H/Au:N/C:C/I:C/A:C", "version": "2.0" }, "exploitabilityScore": 4.9, "impactScore": 10.0, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "nvd@nist.gov", "type": "Primary", "userInteractionRequired": false } ] }, "published": "2008-06-16T18:41:00.000", "references": [ { "source": "cve@mitre.org", "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "source": "cve@mitre.org", "tags": [ "Vendor Advisory" ], "url": "http://secunia.com/advisories/30638" }, { "source": "cve@mitre.org", "url": "http://securityreason.com/securityalert/3944" }, { "source": "cve@mitre.org", "url": "http://securitytracker.com/id?1020241" }, { "source": "cve@mitre.org", "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "source": "cve@mitre.org", "tags": [ "US Government Resource" ], "url": "http://www.kb.cert.org/vuls/id/476345" }, { "source": "cve@mitre.org", "url": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH" }, { "source": "cve@mitre.org", "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "source": "cve@mitre.org", "url": "http://www.securityfocus.com/bid/29634" }, { "source": "cve@mitre.org", "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "source": "cve@mitre.org", "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" }, { "source": "cve@mitre.org", "url": "https://www.exploit-db.com/exploits/6387" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Vendor Advisory" ], "url": "http://secunia.com/advisories/30638" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://securityreason.com/securityalert/3944" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://securitytracker.com/id?1020241" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "US Government Resource" ], "url": "http://www.kb.cert.org/vuls/id/476345" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.securityfocus.com/bid/29634" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://www.exploit-db.com/exploits/6387" } ], "sourceIdentifier": "cve@mitre.org", "vulnStatus": "Deferred", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-119" } ], "source": "nvd@nist.gov", "type": "Primary" } ] }
CVE-2008-2639 (GCVE-0-2008-2639)
Vulnerability from cvelistv5
- n/a
▼ | URL | Tags |
---|---|---|
http://www.vupen.com/english/advisories/2008/1834/references | vdb-entry, x_refsource_VUPEN | |
http://www.kb.cert.org/vuls/id/CTAR-7ENQNH | x_refsource_CONFIRM | |
http://www.coresecurity.com/?action=item&id=2186 | x_refsource_MISC | |
http://isc.sans.org/diary.html?storyid=4556 | x_refsource_MISC | |
http://secunia.com/advisories/30638 | third-party-advisory, x_refsource_SECUNIA | |
http://securitytracker.com/id?1020241 | vdb-entry, x_refsource_SECTRACK | |
https://www.exploit-db.com/exploits/6387 | exploit, x_refsource_EXPLOIT-DB | |
http://www.kb.cert.org/vuls/id/476345 | third-party-advisory, x_refsource_CERT-VN | |
http://www.securityfocus.com/bid/29634 | vdb-entry, x_refsource_BID | |
http://www.securityfocus.com/archive/1/493272/100/0/threaded | mailing-list, x_refsource_BUGTRAQ | |
http://securityreason.com/securityalert/3944 | third-party-advisory, x_refsource_SREASON | |
https://exchange.xforce.ibmcloud.com/vulnerabilities/42992 | vdb-entry, x_refsource_XF |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-07T09:05:30.329Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "name": "ADV-2008-1834", "tags": [ "vdb-entry", "x_refsource_VUPEN", "x_transferred" ], "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "name": "30638", "tags": [ "third-party-advisory", "x_refsource_SECUNIA", "x_transferred" ], "url": "http://secunia.com/advisories/30638" }, { "name": "1020241", "tags": [ "vdb-entry", "x_refsource_SECTRACK", "x_transferred" ], "url": "http://securitytracker.com/id?1020241" }, { "name": "6387", "tags": [ "exploit", "x_refsource_EXPLOIT-DB", "x_transferred" ], "url": "https://www.exploit-db.com/exploits/6387" }, { "name": "VU#476345", "tags": [ "third-party-advisory", "x_refsource_CERT-VN", "x_transferred" ], "url": "http://www.kb.cert.org/vuls/id/476345" }, { "name": "29634", "tags": [ "vdb-entry", "x_refsource_BID", "x_transferred" ], "url": "http://www.securityfocus.com/bid/29634" }, { "name": "20080611 CORE-2008-0125: CitectSCADA ODBC service vulnerability", "tags": [ "mailing-list", "x_refsource_BUGTRAQ", "x_transferred" ], "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "name": "3944", "tags": [ "third-party-advisory", "x_refsource_SREASON", "x_transferred" ], "url": "http://securityreason.com/securityalert/3944" }, { "name": "citectscada-odbc-bo(42992)", "tags": [ "vdb-entry", "x_refsource_XF", "x_transferred" ], "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "product": "n/a", "vendor": "n/a", "versions": [ { "status": "affected", "version": "n/a" } ] } ], "datePublic": "2008-06-11T00:00:00", "descriptions": [ { "lang": "en", "value": "Stack-based buffer overflow in the ODBC server service in Citect CitectSCADA 6 and 7, and CitectFacilities 7, allows remote attackers to execute arbitrary code via a long string in the second application packet in a TCP session on port 20222." } ], "problemTypes": [ { "descriptions": [ { "description": "n/a", "lang": "en", "type": "text" } ] } ], "providerMetadata": { "dateUpdated": "2018-10-11T19:57:01", "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "shortName": "mitre" }, "references": [ { "name": "ADV-2008-1834", "tags": [ "vdb-entry", "x_refsource_VUPEN" ], "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "tags": [ "x_refsource_CONFIRM" ], "url": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH" }, { "tags": [ "x_refsource_MISC" ], "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "tags": [ "x_refsource_MISC" ], "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "name": "30638", "tags": [ "third-party-advisory", "x_refsource_SECUNIA" ], "url": "http://secunia.com/advisories/30638" }, { "name": "1020241", "tags": [ "vdb-entry", "x_refsource_SECTRACK" ], "url": "http://securitytracker.com/id?1020241" }, { "name": "6387", "tags": [ "exploit", "x_refsource_EXPLOIT-DB" ], "url": "https://www.exploit-db.com/exploits/6387" }, { "name": "VU#476345", "tags": [ "third-party-advisory", "x_refsource_CERT-VN" ], "url": "http://www.kb.cert.org/vuls/id/476345" }, { "name": "29634", "tags": [ "vdb-entry", "x_refsource_BID" ], "url": "http://www.securityfocus.com/bid/29634" }, { "name": "20080611 CORE-2008-0125: CitectSCADA ODBC service vulnerability", "tags": [ "mailing-list", "x_refsource_BUGTRAQ" ], "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "name": "3944", "tags": [ "third-party-advisory", "x_refsource_SREASON" ], "url": "http://securityreason.com/securityalert/3944" }, { "name": "citectscada-odbc-bo(42992)", "tags": [ "vdb-entry", "x_refsource_XF" ], "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" } ], "x_legacyV4Record": { "CVE_data_meta": { "ASSIGNER": "cve@mitre.org", "ID": "CVE-2008-2639", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "n/a", "version": { "version_data": [ { "version_value": "n/a" } ] } } ] }, "vendor_name": "n/a" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "Stack-based buffer overflow in the ODBC server service in Citect CitectSCADA 6 and 7, and CitectFacilities 7, allows remote attackers to execute arbitrary code via a long string in the second application packet in a TCP session on port 20222." } ] }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "ADV-2008-1834", "refsource": "VUPEN", "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "name": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH", "refsource": "CONFIRM", "url": "http://www.kb.cert.org/vuls/id/CTAR-7ENQNH" }, { "name": "http://www.coresecurity.com/?action=item\u0026id=2186", "refsource": "MISC", "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "name": "http://isc.sans.org/diary.html?storyid=4556", "refsource": "MISC", "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "name": "30638", "refsource": "SECUNIA", "url": "http://secunia.com/advisories/30638" }, { "name": "1020241", "refsource": "SECTRACK", "url": "http://securitytracker.com/id?1020241" }, { "name": "6387", "refsource": "EXPLOIT-DB", "url": "https://www.exploit-db.com/exploits/6387" }, { "name": "VU#476345", "refsource": "CERT-VN", "url": "http://www.kb.cert.org/vuls/id/476345" }, { "name": "29634", "refsource": "BID", "url": "http://www.securityfocus.com/bid/29634" }, { "name": "20080611 CORE-2008-0125: CitectSCADA ODBC service vulnerability", "refsource": "BUGTRAQ", "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "name": "3944", "refsource": "SREASON", "url": "http://securityreason.com/securityalert/3944" }, { "name": "citectscada-odbc-bo(42992)", "refsource": "XF", "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" } ] } } } }, "cveMetadata": { "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "assignerShortName": "mitre", "cveId": "CVE-2008-2639", "datePublished": "2008-06-16T18:26:00", "dateReserved": "2008-06-09T00:00:00", "dateUpdated": "2024-08-07T09:05:30.329Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }
var-200806-0031
Vulnerability from variot
Stack-based buffer overflow in the ODBC server service in Citect CitectSCADA 6 and 7, and CitectFacilities 7, allows remote attackers to execute arbitrary code via a long string in the second application packet in a TCP session on port 20222. Citect Made by company CitectSCADA Contains a buffer overflow vulnerability. Citect CitectSCADA Is SCADA (Supervisory Control And Data Acquisition) Software used for monitoring and control in the system. CitectSCADA Contains a buffer overflow vulnerability because it cannot properly handle crafted requests from clients.Arbitrary code is executed by a remote party or service operation is interrupted (DoS) There is a possibility of being attacked.
Citect SCADA and CitectFacilities include ODBC server functionality to provide remote SQL access to relational databases. The ODBC server component listens to client requests from the network on the port 20222 / tcp by default. The application layer protocol on TCP reads the 4-byte initial message to specify the length of the data in the next message, and then sockets from the same TCP. Word reads the next message of this length, where the first 5 bytes are a fixed header. After the second message in the network is read into the buffer, the data is copied to a fixed-size internal buffer on the stack.
Due to the lack of a correct length check of the data read, memory copy operations using fixed-size target buffers allocated on the stack may overflow, allowing unauthenticated remote attackers to execute arbitrary instructions on the vulnerable system . CitectSCADA is prone to a remote stack-based buffer-overflow vulnerability because it fails to perform adequate boundary checks on user-supplied data. Attackers can exploit this issue to execute arbitrary code in the context of the application. Failed attacks will likely cause denial-of-service conditions. ----------------------------------------------------------------------
Want a new job?
http://secunia.com/secunia_security_specialist/ http://secunia.com/hardcore_disassembler_and_reverse_engineer/
International Partner Manager - Project Sales in the IT-Security Industry: http://corporate.secunia.com/about_secunia/64/
TITLE: Citect Products ODBC Server Component Buffer Overflow
SECUNIA ADVISORY ID: SA30638
VERIFY ADVISORY: http://secunia.com/advisories/30638/
CRITICAL: Moderately critical
IMPACT: DoS, System access
WHERE:
From local network
SOFTWARE: CitectFacilities 7.x http://secunia.com/product/19043/ CitectSCADA 6.x http://secunia.com/product/19041/ CitectSCADA 7.x http://secunia.com/product/19042/
DESCRIPTION: Core Security Technologies has reported a vulnerability in CitectSCADA and CitectFacilities, which can be exploited by malicious people to cause a DoS (Denial of Service) or compromise a vulnerable system.
The vulnerability is reported in the following versions: * CitectSCADA v6 * CitectSCADA v7 * CitectFacilities v7
SOLUTION: Contact the vendor for patches.
PROVIDED AND/OR DISCOVERED BY: Sebasti\xe1n Mu\xf1iz, Core Security Technologies
ORIGINAL ADVISORY: CORE-2008-0125: http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2186
OTHER REFERENCES: US-CERT VU#476345: http://www.kb.cert.org/vuls/id/476345
About: This Advisory was delivered by Secunia as a free service to help everybody keeping their systems up to date against the latest vulnerabilities.
Subscribe: http://secunia.com/secunia_security_advisories/
Definitions: (Criticality, Where etc.) http://secunia.com/about_secunia_advisories/
Please Note: Secunia recommends that you verify all advisories you receive by clicking the link. Secunia NEVER sends attached files with advisories. Secunia does not advise people to install third party patches, only use those supplied by the vendor. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
~ Core Security Technologies - CoreLabs Advisory ~ http://www.coresecurity.com/corelabs/
~ CitectSCADA ODBC service vulnerability
Advisory Information
Title: CitectSCADA ODBC service vulnerability Advisory ID: CORE-2008-0125 Advisory URL: http://www.coresecurity.com/?action=item&id=2186 Date published: 2008-06-11 Date of last update: 2008-06-10 Vendors contacted: Citect Release mode: Coordinated release
Vulnerability Information
Class: Buffer overflow
Remotely Exploitable: Yes
Locally Exploitable: Yes
Bugtraq ID: 29634
CVE Name: CVE-2008-2639
Vulnerability Description
Citect is a supplier of industrial automation software with headquarters in Australia and over 20 offices in Oceania, South East Asia, China, Japan, the Americas, Europe, Africa and the Middle East. Citect's products are distributed in over 80 countries through a network of more than 500 partners. According to Citect's website [1] the company, a fully owned subsidiary of Schneider Electric, has more than 150,000 licenses of its software sold to date. Citect's products are used by organizations worldwide in numerous industries including Aerospace & Defense, Oil & Gas, Power/Utilities, Chemical, Pharmaceutical, Manufacturing and others. with an integrated Human Machine Interface (HMI) / SCADA solution to deliver a scalable and reliable control and monitoring system. The system is composed by software installed on standard computer equipment running on commercial-of-the-shelf Microsoft Windows operating systems. To accomplish such goal the would-be attacker must be able to connect to the vulnerable service on a TCP high-port.
Vulnerable Packages
. CitectSCADA v6 . CitectSCADA v7 . CitectFacilities v7
Non-vulnerable Packages
. Contact the vendor for fixed versions of the product.
Vendor Information, Solutions and Workarounds
In general process control networks should be physically isolated from corporate or other publicly accessible data networks as such an isolated network will limit the exposure of systems with network facing vulnerabilities only to accidental disruption or potentially malicious users or systems within the process control network itself.
However, if physical isolation of the process control network is not feasible it is strongly recommended to enforce and monitor strict network access control mechanisms to verify that only the absolute minimal required set of systems from both within and outside the process control network are allowed to connect to any systems within the process control network. In this particular case, access control mechanisms on both end-systems and network boundary devices such as firewalls and IPSes must ensure that only hardened and trusted systems from that minimal set can connect to systems in the process control network running potentially vulnerable software. Nonetheless systems on that minimal set must still be considered potential attack vectors into the process control network and should they become compromised, providers of transitive trust from the process control network to external untrusted systems.
Besides the recommendation of a secure network architecture with strict network access control measures, OS hardening and other sound system administration practices a specific workaround for the vulnerability reported in this advisory is provided below.
The vulnerability is located in the ODBC server service, vulnerable organizations that do not require ODBC connectivity may disable the service with no adverse effects to the CitectSCADA software. Installations that require ODBC connectivity to SQL databases, spreadsheets, etc. will suffer loss of connection with ODBC data sources if this workaround is applied. Vulnerable organizations should obtain positive verification that ODBC connectivity is not necessary in their installation and prepare appropriate contingency procedures before the workaround is applied.
Vendor statement:
CitectSCADA is not designed to be accessible on public networks and recommends that the SCADA and control networks be protected by firewall or similar on live sites.
The system must be network hardened regardless of the corrupt packet software change to ensure a secure system given the likelihood that on the same network are open industry standard protocol devices perhaps communicating via ethernet.
Please follow this link on Citect website under "Industries and Solutions" for security, that provides some information for customers interested in securing their SCADA systems: http://www.citect.com/index.php?option=com_content&task=view&id=186&Itemid=322
Credits
This vulnerability was discovered and researched by Sebastian Mu\xf1iz from the Core IMPACT Exploit Writers Team (EWT) at Core Security Technologies. Exploitation was further investigated by Nicolas Economou also from the Core IMPACT Exploit Writers Team (EWT).
Core would also like to thank Paul Fahey of AusCERT, Gaston Franco and Patricia Prandini of ArCERT and Art Manion and Chris Taschner of CERT/CC for their assistance during the vulnerability reporting process.
This bug is a textbook example of a classic stack-based buffer overflow that can be exploited by overwriting the return address of the currently running thread. The following binary excerpt shows the nature of the problem:
/-----------
~ .text:0051BC33 loc_51BC33: ~ .text:0051BC33 lea ecx, [ebp+pDestBuffer] ~ .text:0051BC39 push ecx ; stack based buffer ~ .text:0051BC3A mov edx, [ebp+arg_0] ~ .text:0051BC3D push edx ; class that contains packet ~ .text:0051BC3E call sub_52125A ; memcpy
- -----------/
Report Timeline
. 2008-01-30: Initial contact mail sent by Core to Citect's support team. 2008-01-30: Additional mail sent to Citect support team asking for a software security contact at Citect. 2008-01-30: Email from Citect's support team acknowledging notification and requesting information in plaintext. 2008-02-06: Core sends the draft advisory, including proof of concept code to demonstrate the vulnerability. 2008-02-28: Core requests a response from the vendor and asks for the vendor's plan to release fixes to vulnerable products. 2008-03-06: Email from the vendor's technical architect confirms reception of the report and indicating that there are not concerns around publication of a security advisory disclosing the vulnerability. The vendor asks for a phone conference to ensure that both Core and Citect have a common understanding of the issue and expresses the possibility of adding additional information to the advisory. The vendor also states that it will formulate a plan for handling this issue. 2008-03-12: Core asks to continue the discussion concerning the vulnerability by mail so as to have all the involved parties informed simultaneously and all communications documented. Core requests confirmation that the vendor has been able to reproduce the vulnerability and requests details concerning the plan to release fixes and asks for the additional information that the vendor would like to include in the advisory (in the "vendor information" section). Core reminds the vendor that the original publication date of the advisory was February 25th and states that the publication of the advisory is now re-scheduled to March 24th because fixed versions were not available at the date initially scheduled. 2008-03-25: Vendor confirms that it reproduced and identified the vulnerability and indicates that the official stance is that CitectSCADA is not designed to be accessible on public networks and recommends that SCADA and control networks are protected by firewalls and other security measures on live sites. The vendor also states that it has no immediate plans to support CitectSCADA on public networks but is investigating the possibility of having a security audit of the product. 2008-03-25: Core notifies the vendor the intention to release the advisory on March 26th given that the vendor has no immediate plans for fixing the vulnerability. 2008-03-26: Core consults under NDA with a process control security expert to obtain a better understanding of the scope and impact of the vulnerability. The specific technical details about the vulnerability are not disclosed, only the general type of bug and the specific TCP port on which the vulnerable service listens are discussed. 2008-04-02: Core revisits its current plan to disclose the vulnerability and decides to get Computer Emergency Response Teams (CERTs) involved in the process. Core notifies the vendor that it will postpone the publication of the advisory, and that it will contact the Computer Emergency Response Teams (CERTs) of countries were Core has physical offices (Argentina and USA) and the country were Citect has its headquarters (Australia). Core will then determine the contents and date of publication for the security advisory based on further communication with the vendor and CERTs and more precise details that the vendor may provide regarding availability of fixes. 2008-04-02: Core notifies the vendor that it will contact the CERTs of Australia, USA and Argentina. Core reminds the vendor that the vulnerability reported is a classic example of a stack-based buffer overflow bug trivial to exploit in present times and that although the previous email from the vendor provided a vague statement indicating that "the scenario is under consideration for the next release", to date there has not been any concrete details about development and release of fixes or a firm commitment to any specific date to release them. 2008-04-08: Core sends an initial notification to AusCERT, CERT/CC and ArCert including a draft advisory describing the bug and the vendor's contact information, requesting an acknowledgement within 2 working days. 2008-04-08: AusCERT acknowledges reception of the advisory
. 2008-04-09: ArCERT acknowledges reception of the advisory
. 2008-04-10: CERT/CC acknowledges reception of the advisory on a phone call
. 2008-04-10: AusCERT notifies Core that so far it has not been able to contact the vendor and asks for approval to disseminate the information to the Australian government and other national and international entities overlooking national infrastructure security. AusCERT also asks if CORE intends to publish the advisory and if so requests some time to be able to notify affected organizations. Meanwhile AusCERT indicates that it will continue to try to work with the vendor. 2008-04-10: Core responds that it has no problems with AusCERT notifying other parties that may be able to better prepare risk mitigation procedures and/or work more closely with the vendor towards development and release of a fix. However, Core asks to keep the dissemination of the information to a minimum in order to avoid a potential leak. Core indicates that it has asked the vendor to provide concrete details about how and when it plans to address the issue and that based on the response to that question it will determine a publication date for the security advisory. Lacking a response from the vendor, Core will determine the publication date based on the feedback received from the CERTs and the progress of their preparations to address the report. 2008-04-10: AusCERT asks if it is ok to contact other CERTs and international government communities to make them aware of the issue and to ensure everyone is prepared when the report is published. 2008-04-10: Core response indicating that it is ok to contact any organization that AusCERT deems relevant for the stated purpose
. 2008-04-10: ArCert reports that it will start gathering information about appropriate organizations in Argentina to report the problem and start contacting them. 2008-04-11: CERT/CC reports that US-CERT has been made aware of the issue and will be kept updated going forward. If AusCERT is already in contact with the vendor CERT/CC will standby and follow AusCERT's lead. 2008-04-14: AusCERT reports that after several communication attempts the vendor said that it will address the issue in the next release of the product (by mid-year) and release a patch in a couple of months. However, the information is not to be considered an official statement and there is no official indication of a plan to provide immediate resolution. 2008-04-14: CERT/CC asks if Core will publish the advisory before mid-year and states concerns about the potential time elapsed between advisory publication and release of the fix. CERT/CC will likely put out information soon after Core does and expresses its interest to receive more information from the vendor regarding their response plan. 2008-04-14: AusCERT notes that Core has given the CERTs the time to notify possibly affected organizations before the report is published and requests any specific questions to be asked to the vendor. 2008-04-14: Core states that it is entirely possible to re-visit the publication date of the report (which has been done twice so far) but to do so Core requires concrete details and a committed date for the release of a fix noting that it wasn't until AusCERT's email from April 14th that the possibility that the vendor would release of a patch seemed realistic. Core is willing to postpone publication of the report provided that the vendor commits to release a fix no later than June 30th (the upper bound to the promised mid-year deadline indicated by the vendor). Core also reminds the CERTs that its intent in notifying them of the bug was to help to coordinate a way to address the bug should an official patch or fix is not made available by the vendor. 2008-04-24: Core sends an email to the 3 CERTs requesting a status update and any further details about the availability of fixes. Core would like to set a final date for the publication of its report. 2008-04-28: AusCERT indicates that after several calls and messages, the vendor has stated that it does not publish specific release schedules for updates and does not indicate what will or will not be their contents and that once a release is finalized all relevant materials are updated to reflect that fact. AusCERT asks about Core's plans regarding the issue. 2008-04-28: CERT/CC suggests that in light of the vendor statement one last effort should be attempted, setting a date for publication one or two weeks into the future and presenting the final drafts of the report to the vendor. 2008-04-28: Core sets the advisory publication date to May 12th and indicates to the three CERTs that the date is considered final unless concrete details about a patch release schedule are communicated no later than May 8th. The vendor has already been sent drafts of the advisory, the last one sent on March 25th, and Core has little confidence that the current status process will change in a positive manner. Core will consider the time up to May 12th as a period to finalize the preparation of guidance documents about how to deal with the issue without an official fix available. Should such a document be provided, Core is willing and open to include its recommendations in the security advisory. 2008-05-06: Core informs the CERTs that it is still editing its security advisory and that once the final draft is ready it will be sent for review to the vendor and the CERTs before it is published. Core informs that it will also issue a press release disclosing the issue and invites spokesmen from any of the CERTs to participate with a quote should they want to do so. 2008-05-08: CERT/CC acknowledges Core's email and thanks for the update indicating that it will not participate in a press release. 2008-05-14: Core sends its final draft of the security advisory to Citect and the 3 CERTs indicating that the publication date is set to May 19th, 2008 at approximately 3pm UTC. Should the vendor or the CERTS have any official comments or statements or workarounds that they would like to be included in Core's advisory they must be provided them by email no later than Friday May 16th 2008 at 9pm (UTC). 2008-05-15: Email from the vendor indicating the Citect has allocated resources to address the issue and is pleased to advise that a patch will be available by the end of May. The vendor assumes that publication of the advisory will be postponed given Core's previous email from April 14th stating that it is willing to review the publication date if the vendor commits to releasing a fix no later than June 30th. 2008-05-16: Email from CERT/CC asking about Core's plan to publish the advisory and stating that CERT/CC is inclined to hold off publication for a couple of weeks provided that Core does the same. JPCERT has been informed of the vulnerability to prepare for the upcoming disclosure. 2008-05-16: Core sends email to Citect and the three CERTs stating that publication of the advisory has been re-scheduled to June 2nd 2008 and reiterating that should the vendor want to include additional information or specific pointers to the patch it should be provided at least a day in advance. 2008-05-28: Core sends a follow up to the email sent on May 16th requesting confirmation that Citect is on track to release fixes for the vulnerability. Core had re-scheduled publication of the security advisory to June 2nd, 2008 (next Monday) and wants to confirm that software fixes will be ready to roll out and to provide the opportunity to include in the advisory any official guidelines on how to obtain them and/or any alternative workarounds to the problem. Specific questions about the potential workaround of disabling the vulnerable service are sent to the vendor as well as a request to provide a list of both vulnerable and not vulnerable packages. This information should be received no later than Friday June 30th, 2008 at 1pm UTC. 2008-06-01: Email received from the vendor stating: "The fix is on track and is currently in code review and testing stage. We will advise when and how the patch will be released". 2008-06-01: Core asks if the vendor has a concrete estimated date for the patch release. It is noted that publication of the security advisory was re-scheduled to June 2nd, 2008 on the basis of the vendor's commitment to release fixes "by the end of May" as indicated in the vendor's email from May 15th 2008. May is already past and Core still has no concrete details about when and how the fixes will be available. Core also notes that the previous email from May 28th 2008 had specific questions that may help craft guidance and recommendations for vulnerable organizations to mitigate risk due to the vendor's software security exposure and asks if the vendor is able to provide answers to those specific inquires. Core also states that it would like to discuss with the CERTs any specific details and information about their plans to address this issue in the upcoming week. In the absence of concrete fix details and workarounds from the vendor Core would like to coordinate with CERTs the dissemination of information to help reduce risk to vulnerable organizations worldwide. 2008-06-01: AusCERT indicates that it's ready for the publication and that it will publish its own report after Core has done so. 2008-06-04: Email from CERT/CC asking for a status update from Core and noting that neither the vendor patches nor Core's advisory have been published by June 2nd as planned. CERT/CC is ready to publish information about the issue and is willing to do so on Core's timetable. 2008-06-04: Citect informs that the patch for the reported issue has been completed at the code level and is being QA tested. The timing of software releases is a company commercial decision, and no guarantee of delivery dates is given. However, the vendor anticipates the patch will be published on its website in the next day or so, assuming QA approval is given. The vendor informs that the suggested workaround of disabling the ODBC server is viable for users that do not need this functionality (most users of CitectSCADA) and would not affect the operation of the software in any other way. The vendor states that "Although this patch will be made available to our supported customers, Citect maintains the stated stance that under NO circumstances should any SCADA/PLC/DCS/RTU/Process Control network should ever be exposed unprotected to the internet. The network should either be securely firewalled or better still isolated, or otherwise protected using approved IT security methodology. Citect has previously published security recommendations in a whitepaper located on our website at http://www.citect.com/documents/whitepapers/SCADA%20Security%20Whitepaper.pdf "SECURING AN INTEGRATED SCADA SYSTEM - Network Security & SCADA Systems Whitepaper". The vendor also indicates that "copies of the security alert report appear to have been circulated before the advised date of publication, contrary to the undertaking given to Citect."
. 2008-06-04: Core's email to Citect, AusCERT, CERT/CC and ArCert informing them that publication of the security advisory has now been re-scheduled to June 11th 2008. The date is final. The advisory will include references to the vendor's security recommendations and white paper as well as the proposed workaround. Core also indicates that to date the company has not published any report about the issue and has no indication of any such reports circulating "in the wild" but cannot discard that as a possibility given that the vendor's lack of proper secure communications procedures forced all the involved parties to communicate without any form of email encryption and that those communications have occurred over a public network such as the Internet for a period of over 4 months. 2008-06-04: Email from CERT/CC indicating that it will too publish a report on June 11th also noting the importance of sound system administration practices such as disabling unneeded features and a secure network architecture. CERT/CC agrees on the need of isolated or otherwise secured process control networks but indicates that in practice that is not always the case. Further information about any potential information leak is requested. 2008-06-10: Final draft of the advisory sent to Citect and CERTs, asking for confirmation that patches are now available. 2008-06-10: Citect confirms that patches are available to customers upon request and reiterates that the vendor's official stance is that the control network must be secured, and customers requesting the patch will be offered advice and links on how to do this. 2008-06-10: CERT/CC asks for any official guidance or wording that could be used in documents to direct readers appropriately. For example, an URL to a support/contact web site, or a case number. 2008-06-11: Security advisory CORE-2008-0125 published.
References
[1] Citect Corporate Profile http://www.citect.com/index.php?option=com_content&task=view&id=94&Itemid=151
About CoreLabs
CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs/.
About Core Security Technologies
Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.
Disclaimer
The contents of this advisory are copyright (c) 2008 Core Security Technologies and (c) 2008 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.
GPG/PGP Keys
This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhP2lEACgkQyNibggitWa29yQCdHfYtgLzOvys9Msi95eqF8H/X ADEAoKB9r52U9KXlEvBn5GgCaqXqC8OG =5qtX -----END PGP SIGNATURE-----
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-200806-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": "citectscada", "scope": "eq", "trust": 1.9, "vendor": "citect", "version": "7" }, { "model": "citectscada", "scope": "eq", "trust": 1.9, "vendor": "citect", "version": "6" }, { "model": "citectfacilities", "scope": "eq", "trust": 1.9, "vendor": "citect", "version": "7" }, { "model": null, "scope": null, "trust": 0.8, "vendor": "citect", "version": null }, { "model": "citectfacilities", "scope": "eq", "trust": 0.8, "vendor": "citect", "version": "v7" }, { "model": "citectscada", "scope": "eq", "trust": 0.8, "vendor": "citect", "version": "v6" }, { "model": "citectscada", "scope": "eq", "trust": 0.8, "vendor": "citect", "version": "v7" }, { "model": null, "scope": null, "trust": 0.6, "vendor": "none", "version": null }, { "model": null, "scope": "eq", "trust": 0.4, "vendor": "citectfacilities", "version": "7" }, { "model": null, "scope": "eq", "trust": 0.4, "vendor": "citectscada", "version": "6" }, { "model": null, "scope": "eq", "trust": 0.4, "vendor": "citectscada", "version": "7" } ], "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CERT/CC", "id": "VU#476345" }, { "db": "CNVD", "id": "CNVD-2008-2883" }, { "db": "BID", "id": "29634" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "CNNVD", "id": "CNNVD-200806-217" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "configurations": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/configurations#", "children": { "@container": "@list" }, "cpe_match": { "@container": "@list" }, "data": { "@container": "@list" }, "nodes": { "@container": "@list" } }, "data": [ { "CVE_data_version": "4.0", "nodes": [ { "cpe_match": [ { "cpe22Uri": "cpe:/a:citect:citectfacilities", "vulnerable": true }, { "cpe22Uri": "cpe:/a:citect:citectscada", "vulnerable": true } ], "operator": "OR" } ] } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2008-001454" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Sebastian Mu\u0026ntilde;iz", "sources": [ { "db": "CNNVD", "id": "CNNVD-200806-217" } ], "trust": 0.6 }, "cve": "CVE-2008-2639", "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": "HIGH", "accessVector": "NETWORK", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "COMPLETE", "baseScore": 7.6, "confidentialityImpact": "COMPLETE", "exploitabilityScore": 4.9, "id": "CVE-2008-2639", "impactScore": 10.0, "integrityImpact": "COMPLETE", "severity": "HIGH", "trust": 1.8, "vectorString": "AV:N/AC:H/Au:N/C:C/I:C/A:C", "version": "2.0" }, { "accessComplexity": "HIGH", "accessVector": "NETWORK", "authentication": "NONE", "author": "IVD", "availabilityImpact": "COMPLETE", "baseScore": 7.6, "confidentialityImpact": "COMPLETE", "exploitabilityScore": 4.9, "id": "7d760002-463f-11e9-b563-000c29342cb1", "impactScore": 10.0, "integrityImpact": "COMPLETE", "severity": "HIGH", "trust": 0.2, "vectorString": "AV:N/AC:H/Au:N/C:C/I:C/A:C", "version": "2.9 [IVD]" }, { "accessComplexity": "HIGH", "accessVector": "NETWORK", "authentication": "NONE", "author": "IVD", "availabilityImpact": "COMPLETE", "baseScore": 7.6, "confidentialityImpact": "COMPLETE", "exploitabilityScore": 4.9, "id": "b0301a90-23cd-11e6-abef-000c29c66e3d", "impactScore": 10.0, "integrityImpact": "COMPLETE", "severity": "HIGH", "trust": 0.2, "vectorString": "AV:N/AC:H/Au:N/C:C/I:C/A:C", "version": "2.9 [IVD]" } ], "cvssV3": [], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2008-2639", "trust": 1.0, "value": "HIGH" }, { "author": "CARNEGIE MELLON", "id": "VU#476345", "trust": 0.8, "value": "7.35" }, { "author": "NVD", "id": "CVE-2008-2639", "trust": 0.8, "value": "High" }, { "author": "CNNVD", "id": "CNNVD-200806-217", "trust": 0.6, "value": "HIGH" }, { "author": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1", "trust": 0.2, "value": "HIGH" }, { "author": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d", "trust": 0.2, "value": "HIGH" } ] } ], "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CERT/CC", "id": "VU#476345" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "CNNVD", "id": "CNNVD-200806-217" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Stack-based buffer overflow in the ODBC server service in Citect CitectSCADA 6 and 7, and CitectFacilities 7, allows remote attackers to execute arbitrary code via a long string in the second application packet in a TCP session on port 20222. Citect Made by company CitectSCADA Contains a buffer overflow vulnerability. Citect CitectSCADA Is SCADA (Supervisory Control And Data Acquisition) Software used for monitoring and control in the system. CitectSCADA Contains a buffer overflow vulnerability because it cannot properly handle crafted requests from clients.Arbitrary code is executed by a remote party or service operation is interrupted (DoS) There is a possibility of being attacked. \n\n\u00a0Citect SCADA and CitectFacilities include ODBC server functionality to provide remote SQL access to relational databases. The ODBC server component listens to client requests from the network on the port 20222 / tcp by default. The application layer protocol on TCP reads the 4-byte initial message to specify the length of the data in the next message, and then sockets from the same TCP. Word reads the next message of this length, where the first 5 bytes are a fixed header. After the second message in the network is read into the buffer, the data is copied to a fixed-size internal buffer on the stack. \n\n\u00a0Due to the lack of a correct length check of the data read, memory copy operations using fixed-size target buffers allocated on the stack may overflow, allowing unauthenticated remote attackers to execute arbitrary instructions on the vulnerable system . CitectSCADA is prone to a remote stack-based buffer-overflow vulnerability because it fails to perform adequate boundary checks on user-supplied data. \nAttackers can exploit this issue to execute arbitrary code in the context of the application. Failed attacks will likely cause denial-of-service conditions. ----------------------------------------------------------------------\n\nWant a new job?\n\nhttp://secunia.com/secunia_security_specialist/\nhttp://secunia.com/hardcore_disassembler_and_reverse_engineer/\n\nInternational Partner Manager - Project Sales in the IT-Security\nIndustry:\nhttp://corporate.secunia.com/about_secunia/64/\n\n----------------------------------------------------------------------\n\nTITLE:\nCitect Products ODBC Server Component Buffer Overflow\n\nSECUNIA ADVISORY ID:\nSA30638\n\nVERIFY ADVISORY:\nhttp://secunia.com/advisories/30638/\n\nCRITICAL:\nModerately critical\n\nIMPACT:\nDoS, System access\n\nWHERE:\n\u003eFrom local network\n\nSOFTWARE:\nCitectFacilities 7.x\nhttp://secunia.com/product/19043/\nCitectSCADA 6.x\nhttp://secunia.com/product/19041/\nCitectSCADA 7.x\nhttp://secunia.com/product/19042/\n\nDESCRIPTION:\nCore Security Technologies has reported a vulnerability in\nCitectSCADA and CitectFacilities, which can be exploited by malicious\npeople to cause a DoS (Denial of Service) or compromise a vulnerable\nsystem. \n\nThe vulnerability is reported in the following versions:\n* CitectSCADA v6\n* CitectSCADA v7\n* CitectFacilities v7\n\nSOLUTION:\nContact the vendor for patches. \n\nPROVIDED AND/OR DISCOVERED BY:\nSebasti\\xe1n Mu\\xf1iz, Core Security Technologies\n\nORIGINAL ADVISORY:\nCORE-2008-0125:\nhttp://www.coresecurity.com/index.php5?module=ContentMod\u0026action=item\u0026id=2186\n\nOTHER REFERENCES:\nUS-CERT VU#476345:\nhttp://www.kb.cert.org/vuls/id/476345\n\n----------------------------------------------------------------------\n\nAbout:\nThis Advisory was delivered by Secunia as a free service to help\neverybody keeping their systems up to date against the latest\nvulnerabilities. \n\nSubscribe:\nhttp://secunia.com/secunia_security_advisories/\n\nDefinitions: (Criticality, Where etc.)\nhttp://secunia.com/about_secunia_advisories/\n\n\nPlease Note:\nSecunia recommends that you verify all advisories you receive by\nclicking the link. \nSecunia NEVER sends attached files with advisories. \nSecunia does not advise people to install third party patches, only\nuse those supplied by the vendor. -----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n~ Core Security Technologies - CoreLabs Advisory\n~ http://www.coresecurity.com/corelabs/\n\n~ CitectSCADA ODBC service vulnerability\n\n\n*Advisory Information*\n\nTitle: CitectSCADA ODBC service vulnerability\nAdvisory ID: CORE-2008-0125\nAdvisory URL: http://www.coresecurity.com/?action=item\u0026id=2186\nDate published: 2008-06-11\nDate of last update: 2008-06-10\nVendors contacted: Citect\nRelease mode: Coordinated release\n\n\n*Vulnerability Information*\n\nClass: Buffer overflow\nRemotely Exploitable: Yes\nLocally Exploitable: Yes\nBugtraq ID: 29634\t\nCVE Name: CVE-2008-2639\t\n\n\n*Vulnerability Description*\n\nCitect is a supplier of industrial automation software with headquarters\nin Australia and over 20 offices in Oceania, South East Asia, China,\nJapan, the Americas, Europe, Africa and the Middle East. Citect\u0027s\nproducts are distributed in over 80 countries through a network of more\nthan 500 partners. According to Citect\u0027s website [1] the company, a\nfully owned subsidiary of Schneider Electric, has more than 150,000\nlicenses of its software sold to date. Citect\u0027s products are used by\norganizations worldwide in numerous industries including Aerospace \u0026\nDefense, Oil \u0026 Gas, Power/Utilities, Chemical, Pharmaceutical,\nManufacturing and others. with an integrated Human Machine Interface\n(HMI) / SCADA solution to deliver a scalable and reliable control and\nmonitoring system. The system is composed by software installed on\nstandard computer equipment running on commercial-of-the-shelf Microsoft\nWindows operating systems. To\naccomplish such goal the would-be attacker must be able to connect to\nthe vulnerable service on a TCP high-port. \n\n\n*Vulnerable Packages*\n\n. CitectSCADA v6\n. CitectSCADA v7\n. CitectFacilities v7\n\n\n*Non-vulnerable Packages*\n\n. Contact the vendor for fixed versions of the product. \n\n\n*Vendor Information, Solutions and Workarounds*\n\nIn general process control networks should be physically isolated from\ncorporate or other publicly accessible data networks as such an isolated\nnetwork will limit the exposure of systems with network facing\nvulnerabilities only to accidental disruption or potentially malicious\nusers or systems within the process control network itself. \n\nHowever, if physical isolation of the process control network is not\nfeasible it is strongly recommended to enforce and monitor strict\nnetwork access control mechanisms to verify that only the absolute\nminimal required set of systems from both within and outside the process\ncontrol network are allowed to connect to any systems within the process\ncontrol network. In this particular case, access control mechanisms on\nboth end-systems and network boundary devices such as firewalls and\nIPSes must ensure that only hardened and trusted systems from that\nminimal set can connect to systems in the process control network\nrunning potentially vulnerable software. Nonetheless systems on that\nminimal set must still be considered potential attack vectors into the\nprocess control network and should they become compromised, providers of\ntransitive trust from the process control network to external untrusted\nsystems. \n\nBesides the recommendation of a secure network architecture with strict\nnetwork access control measures, OS hardening and other sound system\nadministration practices a specific workaround for the vulnerability\nreported in this advisory is provided below. \n\nThe vulnerability is located in the ODBC server service, vulnerable\norganizations that do not require ODBC connectivity may disable the\nservice with no adverse effects to the CitectSCADA software. \nInstallations that require ODBC connectivity to SQL databases,\nspreadsheets, etc. will suffer loss of connection with ODBC data sources\nif this workaround is applied. Vulnerable organizations should obtain\npositive verification that ODBC connectivity is not necessary in their\ninstallation and prepare appropriate contingency procedures before the\nworkaround is applied. \n\nVendor statement:\n\nCitectSCADA is not designed to be accessible on public networks and\nrecommends that the SCADA and control networks be protected by firewall\nor similar on live sites. \n\nThe system must be network hardened regardless of the corrupt packet\nsoftware change to ensure a secure system given the likelihood that on\nthe same network are open industry standard protocol devices perhaps\ncommunicating via ethernet. \n\nPlease follow this link on Citect website under \"Industries and\nSolutions\" for security, that provides some information for customers\ninterested in securing their SCADA systems:\nhttp://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=186\u0026Itemid=322\n\n\n*Credits*\n\nThis vulnerability was discovered and researched by Sebastian Mu\\xf1iz from\nthe Core IMPACT Exploit Writers Team (EWT) at Core Security\nTechnologies. Exploitation was further investigated by Nicolas Economou\nalso from the Core IMPACT Exploit Writers Team (EWT). \n\nCore would also like to thank Paul Fahey of AusCERT, Gaston Franco and\nPatricia Prandini of ArCERT and Art Manion and Chris Taschner of CERT/CC\nfor their assistance during the vulnerability reporting process. \n\nThis bug is a textbook example of a classic stack-based buffer overflow\nthat can be exploited by overwriting the return address of the currently\nrunning thread. The following binary excerpt shows the nature of the\nproblem:\n\n/-----------\n\n~ .text:0051BC33 loc_51BC33:\n~ .text:0051BC33 lea ecx, [ebp+pDestBuffer]\n~ .text:0051BC39 push ecx ; stack based buffer\n~ .text:0051BC3A mov edx, [ebp+arg_0]\n~ .text:0051BC3D push edx ; class that contains packet\n~ .text:0051BC3E call sub_52125A ; memcpy\n\n- -----------/\n\n\n\n*Report Timeline*\n\n. 2008-01-30:\nInitial contact mail sent by Core to Citect\u0027s support team. 2008-01-30:\nAdditional mail sent to Citect support team asking for a software\nsecurity contact at Citect. 2008-01-30:\nEmail from Citect\u0027s support team acknowledging notification and\nrequesting information in plaintext. 2008-02-06:\nCore sends the draft advisory, including proof of concept code to\ndemonstrate the vulnerability. 2008-02-28:\nCore requests a response from the vendor and asks for the vendor\u0027s plan\nto release fixes to vulnerable products. 2008-03-06:\nEmail from the vendor\u0027s technical architect confirms reception of the\nreport and indicating that there are not concerns around publication of\na security advisory disclosing the vulnerability. The vendor asks for a\nphone conference to ensure that both Core and Citect have a common\nunderstanding of the issue and expresses the possibility of adding\nadditional information to the advisory. The vendor also states that it\nwill formulate a plan for handling this issue. 2008-03-12:\nCore asks to continue the discussion concerning the vulnerability by\nmail so as to have all the involved parties informed simultaneously and\nall communications documented. Core requests confirmation that the\nvendor has been able to reproduce the vulnerability and requests details\nconcerning the plan to release fixes and asks for the additional\ninformation that the vendor would like to include in the advisory (in\nthe \"vendor information\" section). Core reminds the vendor that the\noriginal publication date of the advisory was February 25th and states\nthat the publication of the advisory is now re-scheduled to March 24th\nbecause fixed versions were not available at the date initially scheduled. 2008-03-25:\nVendor confirms that it reproduced and identified the vulnerability and\nindicates that the official stance is that CitectSCADA is not designed\nto be accessible on public networks and recommends that SCADA and\ncontrol networks are protected by firewalls and other security measures\non live sites. The vendor also states that it has no immediate plans to\nsupport CitectSCADA on public networks but is investigating the\npossibility of having a security audit of the product. 2008-03-25:\nCore notifies the vendor the intention to release the advisory on March\n26th given that the vendor has no immediate plans for fixing the\nvulnerability. 2008-03-26:\nCore consults under NDA with a process control security expert to obtain\na better understanding of the scope and impact of the vulnerability. The\nspecific technical details about the vulnerability are not disclosed,\nonly the general type of bug and the specific TCP port on which the\nvulnerable service listens are discussed. 2008-04-02:\nCore revisits its current plan to disclose the vulnerability and decides\nto get Computer Emergency Response Teams (CERTs) involved in the\nprocess. Core notifies the vendor that it will postpone the publication\nof the advisory, and that it will contact the Computer Emergency\nResponse Teams (CERTs) of countries were Core has physical offices\n(Argentina and USA) and the country were Citect has its headquarters\n(Australia). Core will then determine the contents and date of\npublication for the security advisory based on further communication\nwith the vendor and CERTs and more precise details that the vendor may\nprovide regarding availability of fixes. 2008-04-02:\nCore notifies the vendor that it will contact the CERTs of Australia,\nUSA and Argentina. Core reminds the vendor that the vulnerability\nreported is a classic example of a stack-based buffer overflow bug\ntrivial to exploit in present times and that although the previous email\nfrom the vendor provided a vague statement indicating that \"the scenario\nis under consideration for the next release\", to date there has not been\nany concrete details about development and release of fixes or a firm\ncommitment to any specific date to release them. 2008-04-08:\nCore sends an initial notification to AusCERT, CERT/CC and ArCert\nincluding a draft advisory describing the bug and the vendor\u0027s contact\ninformation, requesting an acknowledgement within 2 working days. 2008-04-08:\nAusCERT acknowledges reception of the advisory\n\n. 2008-04-09:\nArCERT acknowledges reception of the advisory\n\n. 2008-04-10:\nCERT/CC acknowledges reception of the advisory on a phone call\n\n. 2008-04-10:\nAusCERT notifies Core that so far it has not been able to contact the\nvendor and asks for approval to disseminate the information to the\nAustralian government and other national and international entities\noverlooking national infrastructure security. AusCERT also asks if CORE\nintends to publish the advisory and if so requests some time to be able\nto notify affected organizations. Meanwhile AusCERT indicates that it\nwill continue to try to work with the vendor. 2008-04-10:\nCore responds that it has no problems with AusCERT notifying other\nparties that may be able to better prepare risk mitigation procedures\nand/or work more closely with the vendor towards development and release\nof a fix. However, Core asks to keep the dissemination of the\ninformation to a minimum in order to avoid a potential leak. Core\nindicates that it has asked the vendor to provide concrete details about\nhow and when it plans to address the issue and that based on the\nresponse to that question it will determine a publication date for the\nsecurity advisory. Lacking a response from the vendor, Core will\ndetermine the publication date based on the feedback received from the\nCERTs and the progress of their preparations to address the report. 2008-04-10:\nAusCERT asks if it is ok to contact other CERTs and international\ngovernment communities to make them aware of the issue and to ensure\neveryone is prepared when the report is published. 2008-04-10:\nCore response indicating that it is ok to contact any organization that\nAusCERT deems relevant for the stated purpose\n\n. 2008-04-10:\nArCert reports that it will start gathering information about\nappropriate organizations in Argentina to report the problem and start\ncontacting them. 2008-04-11:\nCERT/CC reports that US-CERT has been made aware of the issue and will\nbe kept updated going forward. If AusCERT is already in contact with the\nvendor CERT/CC will standby and follow AusCERT\u0027s lead. 2008-04-14:\nAusCERT reports that after several communication attempts the vendor\nsaid that it will address the issue in the next release of the product\n(by mid-year) and release a patch in a couple of months. However, the\ninformation is not to be considered an official statement and there is\nno official indication of a plan to provide immediate resolution. 2008-04-14:\nCERT/CC asks if Core will publish the advisory before mid-year and\nstates concerns about the potential time elapsed between advisory\npublication and release of the fix. CERT/CC will likely put out\ninformation soon after Core does and expresses its interest to receive\nmore information from the vendor regarding their response plan. 2008-04-14:\nAusCERT notes that Core has given the CERTs the time to notify possibly\naffected organizations before the report is published and requests any\nspecific questions to be asked to the vendor. 2008-04-14:\nCore states that it is entirely possible to re-visit the publication\ndate of the report (which has been done twice so far) but to do so Core\nrequires concrete details and a committed date for the release of a fix\nnoting that it wasn\u0027t until AusCERT\u0027s email from April 14th that the\npossibility that the vendor would release of a patch seemed realistic. \nCore is willing to postpone publication of the report provided that the\nvendor commits to release a fix no later than June 30th (the upper bound\nto the promised mid-year deadline indicated by the vendor). Core also\nreminds the CERTs that its intent in notifying them of the bug was to\nhelp to coordinate a way to address the bug should an official patch or\nfix is not made available by the vendor. 2008-04-24:\nCore sends an email to the 3 CERTs requesting a status update and any\nfurther details about the availability of fixes. Core would like to set\na final date for the publication of its report. 2008-04-28:\nAusCERT indicates that after several calls and messages, the vendor has\nstated that it does not publish specific release schedules for updates\nand does not indicate what will or will not be their contents and that\nonce a release is finalized all relevant materials are updated to\nreflect that fact. AusCERT asks about Core\u0027s plans regarding the issue. 2008-04-28:\nCERT/CC suggests that in light of the vendor statement one last effort\nshould be attempted, setting a date for publication one or two weeks\ninto the future and presenting the final drafts of the report to the vendor. 2008-04-28:\nCore sets the advisory publication date to May 12th and indicates to the\nthree CERTs that the date is considered final unless concrete details\nabout a patch release schedule are communicated no later than May 8th. \nThe vendor has already been sent drafts of the advisory, the last one\nsent on March 25th, and Core has little confidence that the current\nstatus process will change in a positive manner. Core will consider the\ntime up to May 12th as a period to finalize the preparation of guidance\ndocuments about how to deal with the issue without an official fix\navailable. Should such a document be provided, Core is willing and open\nto include its recommendations in the security advisory. 2008-05-06:\nCore informs the CERTs that it is still editing its security advisory\nand that once the final draft is ready it will be sent for review to the\nvendor and the CERTs before it is published. Core informs that it will\nalso issue a press release disclosing the issue and invites spokesmen\nfrom any of the CERTs to participate with a quote should they want to do so. 2008-05-08:\nCERT/CC acknowledges Core\u0027s email and thanks for the update indicating\nthat it will not participate in a press release. 2008-05-14:\nCore sends its final draft of the security advisory to Citect and the 3\nCERTs indicating that the publication date is set to May 19th, 2008 at\napproximately 3pm UTC. Should the vendor or the CERTS have any official\ncomments or statements or workarounds that they would like to be\nincluded in Core\u0027s advisory they must be provided them by email no later\nthan Friday May 16th 2008 at 9pm (UTC). 2008-05-15:\nEmail from the vendor indicating the Citect has allocated resources to\naddress the issue and is pleased to advise that a patch will be\navailable by the end of May. The vendor assumes that publication of the\nadvisory will be postponed given Core\u0027s previous email from April 14th\nstating that it is willing to review the publication date if the vendor\ncommits to releasing a fix no later than June 30th. 2008-05-16:\nEmail from CERT/CC asking about Core\u0027s plan to publish the advisory and\nstating that CERT/CC is inclined to hold off publication for a couple of\nweeks provided that Core does the same. JPCERT has been informed of the\nvulnerability to prepare for the upcoming disclosure. 2008-05-16:\nCore sends email to Citect and the three CERTs stating that publication\nof the advisory has been re-scheduled to June 2nd 2008 and reiterating\nthat should the vendor want to include additional information or\nspecific pointers to the patch it should be provided at least a day in\nadvance. 2008-05-28:\nCore sends a follow up to the email sent on May 16th requesting\nconfirmation that Citect is on track to release fixes for the\nvulnerability. Core had re-scheduled publication of the security\nadvisory to June 2nd, 2008 (next Monday) and wants to confirm that\nsoftware fixes will be ready to roll out and to provide the opportunity\nto include in the advisory any official guidelines on how to obtain them\nand/or any alternative workarounds to the problem. Specific questions\nabout the potential workaround of disabling the vulnerable service are\nsent to the vendor as well as a request to provide a list of both\nvulnerable and not vulnerable packages. This information should be\nreceived no later than Friday June 30th, 2008 at 1pm UTC. 2008-06-01:\nEmail received from the vendor stating: \"The fix is on track and is\ncurrently in code review and testing stage. We will advise when and how\nthe patch will be released\". 2008-06-01:\nCore asks if the vendor has a concrete estimated date for the patch\nrelease. It is noted that publication of the security advisory was\nre-scheduled to June 2nd, 2008 on the basis of the vendor\u0027s commitment\nto release fixes \"by the end of May\" as indicated in the vendor\u0027s email\nfrom May 15th 2008. May is already past and Core still has no concrete\ndetails about when and how the fixes will be available. Core also notes\nthat the previous email from May 28th 2008 had specific questions that\nmay help craft guidance and recommendations for vulnerable organizations\nto mitigate risk due to the vendor\u0027s software security exposure and asks\nif the vendor is able to provide answers to those specific inquires. \nCore also states that it would like to discuss with the CERTs any\nspecific details and information about their plans to address this issue\nin the upcoming week. In the absence of concrete fix details and\nworkarounds from the vendor Core would like to coordinate with CERTs the\ndissemination of information to help reduce risk to vulnerable\norganizations worldwide. 2008-06-01:\nAusCERT indicates that it\u0027s ready for the publication and that it will\npublish its own report after Core has done so. 2008-06-04:\nEmail from CERT/CC asking for a status update from Core and noting that\nneither the vendor patches nor Core\u0027s advisory have been published by\nJune 2nd as planned. CERT/CC is ready to publish information about the\nissue and is willing to do so on Core\u0027s timetable. 2008-06-04:\nCitect informs that the patch for the reported issue has been completed\nat the code level and is being QA tested. The timing of software\nreleases is a company commercial decision, and no guarantee of delivery\ndates is given. However, the vendor anticipates the patch will be\npublished on its website in the next day or so, assuming QA approval is\ngiven. The vendor informs that the suggested workaround of disabling\nthe ODBC server is viable for users that do not need this functionality\n(most users of CitectSCADA) and would not affect the operation of the\nsoftware in any other way. \nThe vendor states that \"Although this patch will be made available to\nour supported customers, Citect maintains the stated stance that under\nNO circumstances should any SCADA/PLC/DCS/RTU/Process Control network\nshould ever be exposed unprotected to the internet. The network should\neither be securely firewalled or better still isolated, or otherwise\nprotected using approved IT security methodology. Citect has previously\npublished security recommendations in a whitepaper located on our\nwebsite at\nhttp://www.citect.com/documents/whitepapers/SCADA%20Security%20Whitepaper.pdf\n\"SECURING AN INTEGRATED SCADA SYSTEM - Network Security \u0026 SCADA Systems\nWhitepaper\". The vendor also indicates that \"copies of the security\nalert report appear to have been circulated before the advised date of\npublication, contrary to the undertaking given to Citect.\"\n\n. 2008-06-04:\nCore\u0027s email to Citect, AusCERT, CERT/CC and ArCert informing them that\npublication of the security advisory has now been re-scheduled to June\n11th 2008. The date is final. The advisory will include references to\nthe vendor\u0027s security recommendations and white paper as well as the\nproposed workaround. Core also indicates that to date the company has\nnot published any report about the issue and has no indication of any\nsuch reports circulating \"in the wild\" but cannot discard that as a\npossibility given that the vendor\u0027s lack of proper secure communications\nprocedures forced all the involved parties to communicate without any\nform of email encryption and that those communications have occurred\nover a public network such as the Internet for a period of over 4 months. 2008-06-04:\nEmail from CERT/CC indicating that it will too publish a report on June\n11th also noting the importance of sound system administration practices\nsuch as disabling unneeded features and a secure network architecture. \nCERT/CC agrees on the need of isolated or otherwise secured process\ncontrol networks but indicates that in practice that is not always the\ncase. Further information about any potential information leak is requested. 2008-06-10:\nFinal draft of the advisory sent to Citect and CERTs, asking for\nconfirmation that patches are now available. 2008-06-10:\nCitect confirms that patches are available to customers upon request and\nreiterates that the vendor\u0027s official stance is that the control network\nmust be secured, and customers requesting the patch will be offered\nadvice and links on how to do this. 2008-06-10:\nCERT/CC asks for any official guidance or wording that could be used in\ndocuments to direct readers appropriately. For example, an URL to a\nsupport/contact web site, or a case number. 2008-06-11:\nSecurity advisory CORE-2008-0125 published. \n\n\n\n*References*\n\n[1] Citect Corporate Profile\nhttp://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=94\u0026Itemid=151\n\n\n*About CoreLabs*\n\nCoreLabs, the research center of Core Security Technologies, is charged\nwith anticipating the future needs and requirements for information\nsecurity technologies. We conduct our research in several important\nareas of computer security including system vulnerabilities, cyber\nattack planning and simulation, source code auditing, and cryptography. \nOur results include problem formalization, identification of\nvulnerabilities, novel solutions and prototypes for new technologies. \nCoreLabs regularly publishes security advisories, technical papers,\nproject information and shared software tools for public use at:\nhttp://www.coresecurity.com/corelabs/. \n\n\n*About Core Security Technologies*\n\nCore Security Technologies develops strategic solutions that help\nsecurity-conscious organizations worldwide develop and maintain a\nproactive process for securing their networks. The company\u0027s flagship\nproduct, CORE IMPACT, is the most comprehensive product for performing\nenterprise security assurance testing. CORE IMPACT evaluates network,\nendpoint and end-user vulnerabilities and identifies what resources are\nexposed. It enables organizations to determine if current security\ninvestments are detecting and preventing attacks. Core augments its\nleading technology solution with world-class security consulting\nservices, including penetration testing and software security auditing. \nBased in Boston, MA and Buenos Aires, Argentina, Core Security\nTechnologies can be reached at 617-399-6980 or on the Web at\nhttp://www.coresecurity.com. \n\n\n*Disclaimer*\n\nThe contents of this advisory are copyright (c) 2008 Core Security\nTechnologies and (c) 2008 CoreLabs, and may be distributed freely\nprovided that no fee is charged for this distribution and proper credit\nis given. \n\n\n*GPG/PGP Keys*\n\nThis advisory has been signed with the GPG key of Core Security\nTechnologies advisories team, which is available for download at\nhttp://www.coresecurity.com/files/attachments/core_security_advisories.asc. \n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.8 (MingW32)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niEYEARECAAYFAkhP2lEACgkQyNibggitWa29yQCdHfYtgLzOvys9Msi95eqF8H/X\nADEAoKB9r52U9KXlEvBn5GgCaqXqC8OG\n=5qtX\n-----END PGP SIGNATURE-----\n", "sources": [ { "db": "NVD", "id": "CVE-2008-2639" }, { "db": "CERT/CC", "id": "VU#476345" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "CNVD", "id": "CNVD-2008-2883" }, { "db": "BID", "id": "29634" }, { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "PACKETSTORM", "id": "67260" }, { "db": "PACKETSTORM", "id": "67189" } ], "trust": 3.69 }, "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": "NVD", "id": "CVE-2008-2639", "trust": 3.8 }, { "db": "CERT/CC", "id": "VU#476345", "trust": 3.6 }, { "db": "BID", "id": "29634", "trust": 3.5 }, { "db": "SECUNIA", "id": "30638", "trust": 3.4 }, { "db": "EXPLOIT-DB", "id": "6387", "trust": 2.4 }, { "db": "SECTRACK", "id": "1020241", "trust": 2.4 }, { "db": "VUPEN", "id": "ADV-2008-1834", "trust": 1.6 }, { "db": "SREASON", "id": "3944", "trust": 1.6 }, { "db": "XF", "id": "42992", "trust": 1.4 }, { "db": "CNVD", "id": "CNVD-2008-2883", "trust": 1.0 }, { "db": "CNNVD", "id": "CNNVD-200806-217", "trust": 1.0 }, { "db": "JVNDB", "id": "JVNDB-2008-001454", "trust": 0.8 }, { "db": "BUGTRAQ", "id": "20080611 CORE-2008-0125: CITECTSCADA ODBC SERVICE VULNERABILITY", "trust": 0.6 }, { "db": "MILW0RM", "id": "6387", "trust": 0.6 }, { "db": "IVD", "id": "7D760002-463F-11E9-B563-000C29342CB1", "trust": 0.2 }, { "db": "IVD", "id": "B0301A90-23CD-11E6-ABEF-000C29C66E3D", "trust": 0.2 }, { "db": "PACKETSTORM", "id": "67260", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "67189", "trust": 0.1 } ], "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CERT/CC", "id": "VU#476345" }, { "db": "CNVD", "id": "CNVD-2008-2883" }, { "db": "BID", "id": "29634" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "PACKETSTORM", "id": "67260" }, { "db": "PACKETSTORM", "id": "67189" }, { "db": "CNNVD", "id": "CNNVD-200806-217" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "id": "VAR-200806-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": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CNVD", "id": "CNVD-2008-2883" } ], "trust": 1.613095215 }, "iot_taxonomy": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot_taxonomy#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "category": [ "ICS" ], "sub_category": null, "trust": 1.0 } ], "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CNVD", "id": "CNVD-2008-2883" } ] }, "last_update_date": "2024-11-23T22:32:02.937000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "Securing Your SCADA Network", "trust": 0.8, "url": "http://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=186\u0026Itemid=322" } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2008-001454" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-119", "trust": 1.8 } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "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": 2.8, "url": "http://www.kb.cert.org/vuls/id/476345" }, { "trust": 2.4, "url": "http://secunia.com/advisories/30638" }, { "trust": 2.4, "url": "http://www.securityfocus.com/bid/29634" }, { "trust": 2.4, "url": "http://securitytracker.com/id?1020241" }, { "trust": 2.0, "url": "http://www.coresecurity.com/?action=item\u0026id=2186" }, { "trust": 1.6, "url": "http://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=1374\u0026itemid=223" }, { "trust": 1.6, "url": "http://www.kb.cert.org/vuls/id/ctar-7enqnh" }, { "trust": 1.6, "url": "http://securityreason.com/securityalert/3944" }, { "trust": 1.6, "url": "http://isc.sans.org/diary.html?storyid=4556" }, { "trust": 1.4, "url": "http://www.milw0rm.com/exploits/6387" }, { "trust": 1.4, "url": "http://xforce.iss.net/xforce/xfdb/42992" }, { "trust": 1.2, "url": "http://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=186\u0026itemid=322" }, { "trust": 1.0, "url": "http://www.vupen.com/english/advisories/2008/1834/references" }, { "trust": 1.0, "url": "https://www.exploit-db.com/exploits/6387" }, { "trust": 1.0, "url": "http://www.securityfocus.com/archive/1/493272/100/0/threaded" }, { "trust": 1.0, "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42992" }, { "trust": 0.9, "url": "http://www.coresecurity.com/index.php5?module=contentmod\u0026action=item\u0026id=2186" }, { "trust": 0.9, "url": "http://secunia.com/advisories/30638/" }, { "trust": 0.8, "url": "http://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=26\u0026itemid=29" }, { "trust": 0.8, "url": "http://www.citect.com/documents/news_and_media/pr-citect-address-security.pdf" }, { "trust": 0.8, "url": "http://www.securityfocus.com/bid/29634/discuss" }, { "trust": 0.8, "url": "http://news.infracritical.com/pipermail/scadasec/2008-september/001503.html" }, { "trust": 0.8, "url": "http://www.digitalmunition.com/5ws_of_citect_odbc.txt" }, { "trust": 0.8, "url": "http://www.digitalmunition.com/citect_scada_odbc.rb" }, { "trust": 0.8, "url": "http://www.milw0rm.com/papers/221" }, { "trust": 0.8, "url": "http://www.citect.com/documents/news_and_media/citectscada-security-response.pdf" }, { "trust": 0.8, "url": "http://www.csoonline.com/article/print/448626" }, { "trust": 0.8, "url": "http://www.pcworld.com/businesscenter/article/150888/computer_threat_for_industrial_systems_now_more_serious.html" }, { "trust": 0.8, "url": "http://www.theregister.co.uk/2008/09/19/scada_advisory_pulled/" }, { "trust": 0.8, "url": "http://knowledgebase.citect.com/safetyandsecurity/" }, { "trust": 0.8, "url": "http://www.digitalbond.com/wiki/index.php/citectscada_stack_overflow_vulnerability" }, { "trust": 0.8, "url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2008-2639" }, { "trust": 0.8, "url": "http://www.frsirt.com/english/advisories/2008/1803" }, { "trust": 0.8, "url": "http://jvn.jp/cert/jvnvu476345/" }, { "trust": 0.8, "url": "http://nvd.nist.gov/nvd.cfm?cvename=cve-2008-2639" }, { "trust": 0.6, "url": "http://www.securityfocus.com/archive/1/archive/1/493272/100/0/threaded" }, { "trust": 0.6, "url": "http://www.frsirt.com/english/advisories/2008/1834/references" }, { "trust": 0.3, "url": "http://www.citect.com" }, { "trust": 0.3, "url": "/archive/1/493272" }, { "trust": 0.1, "url": "http://secunia.com/secunia_security_advisories/" }, { "trust": 0.1, "url": "http://secunia.com/product/19041/" }, { "trust": 0.1, "url": "http://secunia.com/hardcore_disassembler_and_reverse_engineer/" }, { "trust": 0.1, "url": "http://secunia.com/sec_adv_unsubscribe/?email=packet%40packetstormsecurity.org" }, { "trust": 0.1, "url": "http://secunia.com/secunia_security_specialist/" }, { "trust": 0.1, "url": "http://secunia.com/product/19042/" }, { "trust": 0.1, "url": "http://corporate.secunia.com/about_secunia/64/" }, { "trust": 0.1, "url": "http://secunia.com/about_secunia_advisories/" }, { "trust": 0.1, "url": "http://secunia.com/product/19043/" }, { "trust": 0.1, "url": "http://www.citect.com/index.php?option=com_content\u0026task=view\u0026id=94\u0026itemid=151" }, { "trust": 0.1, "url": "http://www.coresecurity.com/files/attachments/core_security_advisories.asc." }, { "trust": 0.1, "url": "http://enigmail.mozdev.org" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2008-2639" }, { "trust": 0.1, "url": "http://www.coresecurity.com." }, { "trust": 0.1, "url": "http://www.coresecurity.com/corelabs/." }, { "trust": 0.1, "url": "http://www.coresecurity.com/corelabs/" }, { "trust": 0.1, "url": "http://www.citect.com/documents/whitepapers/scada%20security%20whitepaper.pdf" } ], "sources": [ { "db": "CERT/CC", "id": "VU#476345" }, { "db": "BID", "id": "29634" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "PACKETSTORM", "id": "67260" }, { "db": "PACKETSTORM", "id": "67189" }, { "db": "CNNVD", "id": "CNNVD-200806-217" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CERT/CC", "id": "VU#476345" }, { "db": "CNVD", "id": "CNVD-2008-2883" }, { "db": "BID", "id": "29634" }, { "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "db": "PACKETSTORM", "id": "67260" }, { "db": "PACKETSTORM", "id": "67189" }, { "db": "CNNVD", "id": "CNNVD-200806-217" }, { "db": "NVD", "id": "CVE-2008-2639" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2008-06-11T00:00:00", "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "date": "2008-06-11T00:00:00", "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "date": "2008-06-11T00:00:00", "db": "CERT/CC", "id": "VU#476345" }, { "date": "2008-06-11T00:00:00", "db": "CNVD", "id": "CNVD-2008-2883" }, { "date": "2008-06-11T00:00:00", "db": "BID", "id": "29634" }, { "date": "2008-07-08T00:00:00", "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "date": "2008-06-13T01:45:00", "db": "PACKETSTORM", "id": "67260" }, { "date": "2008-06-11T18:49:38", "db": "PACKETSTORM", "id": "67189" }, { "date": "2008-06-16T00:00:00", "db": "CNNVD", "id": "CNNVD-200806-217" }, { "date": "2008-06-16T18:41:00", "db": "NVD", "id": "CVE-2008-2639" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2008-10-08T00:00:00", "db": "CERT/CC", "id": "VU#476345" }, { "date": "2008-06-11T00:00:00", "db": "CNVD", "id": "CNVD-2008-2883" }, { "date": "2008-09-08T17:51:00", "db": "BID", "id": "29634" }, { "date": "2008-07-08T00:00:00", "db": "JVNDB", "id": "JVNDB-2008-001454" }, { "date": "2009-01-29T00:00:00", "db": "CNNVD", "id": "CNNVD-200806-217" }, { "date": "2024-11-21T00:47:21.547000", "db": "NVD", "id": "CVE-2008-2639" } ] }, "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": "PACKETSTORM", "id": "67189" }, { "db": "CNNVD", "id": "CNNVD-200806-217" } ], "trust": 0.7 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Citect SCADA ODBC Server Remote Stack Overflow Vulnerability", "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CNVD", "id": "CNVD-2008-2883" } ], "trust": 1.0 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Buffer overflow", "sources": [ { "db": "IVD", "id": "7d760002-463f-11e9-b563-000c29342cb1" }, { "db": "IVD", "id": "b0301a90-23cd-11e6-abef-000c29c66e3d" }, { "db": "CNNVD", "id": "CNNVD-200806-217" } ], "trust": 1.0 } }