Vulnerability (computing) 1129827 225778616 2008-07-15T10:37:34Z Tj9991 192259 Reverted edits by [[Special:Contributions/222.124.204.231|222.124.204.231]] to last version by Tj9991 (using [[WP:HG|Huggle]]) {{For|other uses of the word "Vulnerability"|vulnerability}} In [[computer security]], the term '''vulnerability''' is applied to a weakness in a system which allows an attacker to violate the integrity of that system. Vulnerabilities may result from [[strong password|weak passwords]], [[software bug]]s, a [[computer virus]] or other [[malware]], a script [[code injection]], or a [[SQL injection]]. A vulnerability may exist only in theory, or may have a known instance of an [[exploit (computer security)|exploit]]. Constructs in [[computer language|programming languages]] that are difficult to use properly can be a large source of vulnerabilities. ==Causes== {{Cleanup-section|date=June 2008}} *'''Password Management Flaws''' The computer user uses [[Password strength|weak passwords]] that could be discovered by brute force. The computer user stores the password on the computer where a program can access it. Users re-use passwords between many programs and websites. *'''Fundamental Operating System Design Flaws''' – The operating system designer chooses to enforce sub optimal policies on user/program management. For example operating systems with policies such as [[default permit]] grant every program and every user full access to the entire computer. This operating system flaw allows viruses and malware to execute commands on behalf of the administrator. [http://www.ranum.com/security/computer_security/editorials/dumb/] *'''Software Bugs''' – The programmer leaves an exploitable bug in a software program. The software bug may allow an attacker to misuse an application through (for example) bypassing access control checks or executing commands on the system hosting the application. Also the programmer's failure to check the size of data buffers, which can then be [[buffer overflow|overflowed]], causing corruption of the stack or heap areas of memory (including causing the computer to execute code provided by the attacker). *'''Unchecked User Input''' – The program assumes that all user input is safe. Programs that do not check user input can allow unintended direct execution of commands or SQL statements (known as [[Buffer overflow]]s,[[SQL injection]] or other non-validated inputs). ==Vulnerability disclosure== {{POV|date=March 2007}} {{Essay-opinion|date=June 2008}} {{Unreferencedsection|date=June 2008}} The method of disclosing vulnerabilities is a topic of debate in the computer security community. Some advocate immediate [[full disclosure]] of information about vulnerabilities once they are discovered. Others argue for limiting disclosure to the users placed at greatest risk, and only releasing full details after a delay, if ever. Such delays may allow those notified to fix the problem by developing and applying [[patch (computing)|patch]]es, but may also increase the risk to those not privy to full details. This debate has a long history in security; see [[full disclosure]] and [[security through obscurity]]. More recently a new form of commercial vulnerability disclosure has taken shape, as some commercial security companies offer money for exclusive disclosures of [[Zero day attack|Zero Day vulnerabilities]]. Those offers provide a legitimate market for the purchase and sale of vulnerability information from the security community. From the security perspective, a free and public disclosure is only successful if the affected parties get the relevant information prior to potential hackers, if they did not the hackers could take immediate advantage of the reveled exploit. With Security Through Obscurity the same rule applies, but this time rests on the hackers finding the vulnerability themselves, as opposed to being 'told' the information. The disadvantage here is that there is a lower number of people with full knowledge of the vulnerability who can aid in finding similar or related scenarios. It should be unbiased to enable a fair dissemination of security critical information. Most often a channel is considered trusted when it is a widely accepted source of security information in the industry (e.g [[CERT]], [[SecurityFocus]], [[Secunia]] and [http://www.frsirt.com/english FrSIRT]). Analysis and risk rating ensure the quality of the disclosed information. The analysis must include enough details to allow a concerned user of the software to assess his individual risk or take immediate action to protect his assets. == Vulnerability disclosure date == The time of disclosure of a vulnerability is defined differently in the security community and industry. It is most commonly referred to as "a kind of public disclosure of security information by a certain party". Usually, vulnerability information is discussed on a mailing list or published on a security web site and results in a security advisory afterwards. The '''time of disclosure''' is the first date a security vulnerability is described on a channel where the disclosed information on the vulnerability has to fulfil the following requirement: *the information is freely available to the public *the vulnerability information is published by a trusted and independent channel/source *the vulnerability has undergone analysis by experts such that risk rating information is included upon disclosure ==Identifying and removing vulnerabilities== Many software tools exist that can aid in the discovery (and sometimes removal) of vulnerabilities in a computer system. Though these tools can provide an auditor with a good overview of possible vulnerabilities present, they can not replace human judgment. Relying solely on scanners will yield false positives and a limited-scope view of the problems present in the system. Vulnerabilities have been found in every major [[operating system]] including [[Microsoft Windows|Windows]], [[Mac OS]], various forms of [[Unix]] and [[Linux]], [[OpenVMS]], and others. The only way to reduce the chance of a vulnerability being used against a system is through constant vigilance, including careful system maintenance (e.g. applying software patches), best practices in deployment (e.g. the use of [[firewall (networking)|firewalls]] and [[access control]]s) and auditing (both during development and throughout the deployment lifecycle). ==Examples of vulnerabilities== Common types of vulnerabilities include: *[[Memory safety]] violations, such as: **[[Buffer overflow]]s **[[Dangling pointer]]s *[[Data validation|Input validation]] errors, such as: **[[Format string bug]]s **Improperly handling [[Unix shell|shell]] [[metacharacter]]s so they are interpreted **[[SQL injection]] **[[Code injection]] **[[E-mail injection]] **[[Directory traversal]] **[[Cross-site scripting]] in web applications *[[Race conditions]], such as: **[[Time-of-check-to-time-of-use]] bugs **[[Symlink race]]s *[[Confused deputy problem|Privilege-confusion]] bugs, such as: **[[Cross-site request forgery]] in web applications *[[Privilege escalation]] *[[User interface]] failures, such as: **Warning fatigue [http://www.freedom-to-tinker.com/?p=459] or user conditioning [http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf] **[[victim blaming|Blaming the Victim]] Prompting a user to make a security decision without giving the user enough information to answer it [http://blog.mozilla.com/rob-sayre/2007/09/28/blaming-the-victim/] **[[Race Condition]]s [http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/] ==See also== * [[Exploit (computer science)]] * [[Computer security]] * [[Computer insecurity]] * [[Common Vulnerabilities and Exposures]] (CVE) * [[CVSS|Common Vulnerability Scoring System]] (CVSS) * [[Y2K]] == External links == * [http://www.aitcnet.org/isai/ Languages Standard's group]: Guidance for Avoiding Vulnerabilities through Language Selection and Use * [http://www.microsoft.com/technet/archive/community/columns/security/essays/vulnrbl.mspx Microsoft Security Response Center definition] * [http://samate.nist.gov/ NIST Software Assurance Metrics and Tool Evaluation (SAMATE) project] * [http://www.osvdb.org/ Open Source Vulnerability Database homepage] * [http://www.owasp.org/index.php/Category:Vulnerability Open Web Application Security Project] * [http://secwatch.org/ SecWatch Vulnerability Archive] * [http://www.frsirt.com/english FrSIRT Vulnerability Archive] * [http://secunia.com/ Secunia Vulnerability Archive] * [http://www.securityfocus.com/bid SecurityFocus Vulnerability Archive] * [http://www.milw0rm.com/ milw0rm Vulnerability and Exploit Archive] * [http://www.cve.mitre.org/ Common Vulnerabilities and Exposures (CVE)] [[Category:Security exploits]] [[Category:Software testing]] [[Category:Computer security]] [[ca:Vulnerabilitat (informàtica)]] [[de:Sicherheitslücke]] [[es:Agujero de seguridad]] [[fa:آسیب‌پذیری (رایانه)]] [[fr:Vulnérabilité (informatique)]] [[ja:セキュリティホール]] [[pt:Vulnerabilidade (computação)]] [[ru:Уязвимость (компьютерная безопасность)]] [[fi:Tietoturva-aukko]] [[th:ช่องโหว่ของระบบ]] [[uk:Уразливість]] [[zh:计算机安全隐患]]