Hi Theo, Theo de Raadt wrote on Fri, Apr 24, 2020 at 10:57:23AM -0600:
> Somewhere along the line, the web pages were changed to no longer > reference those pages, and that is a shame. > > It is a shame that the old errata pages don't point at those files. > > They aren't quite in the same format, but why not try to show > the history of our work? > > If we start saying we don't need to document 20 years ago, what's > the difference with saying we don't need to document 2 years ago? > History is nice to have, and absence of historical context is dissapointing. I agree with what you are saying. So here is a patch to reference those files from our web pages. * Even though the patch creates errata20.html, i don't include adding links from all errata pages to errata20.html into this patch, to avoid making the patch unreadable from churn. If people agree with me that such links should be on each page, i can do that afterwards with a separate commit. * While most errata entries describe the problem with a few lines of text, my aim for this patch was to kept the changes minimal, to make it easy to review the patch. So i'm just saying in one word, or in a few words, which subsystem the problem was related to. If people think more text should be added to the errata pages in addition to the links, that can be done in later patches. * sni_20_tgetent.txt is strange in so far as it appeared quite late, way after OpenBSD 2.1, but it says that "Versions of OpenBSD newer than 2.0 are NOT vulnerable to this problem." For now, i kept in in the chronological order anyway. * The files res_random.txt and sni_12_resolverid.txt contain essentially the same text, except that each of them contains a very small amount of errors or omissions apparent by looking at the diff between the two. I suggest keeping sni_12_resolverid.txt because that's the name better fitting the names of other files, fixing some incorrect line breaks in that file, and deleting the redundant copy res_random.txt. * The file ssh_trojan.txt is very special. It is not about any bug in the OpenBSD source code at all, so no patching was ever needed for it. Consequently, i don't think it belongs on the errata* pages, and linking it should be done separately if desired, in a different way, probably from somewhere below the OpenSSH site. OK? Ingo Index: errata20.html =================================================================== RCS file: errata20.html diff -N errata20.html --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ errata20.html 24 Apr 2020 20:25:21 -0000 @@ -0,0 +1,119 @@ +<!doctype html> +<html lang=en id=errata> +<meta charset=utf-8> + +<title>OpenBSD 2.0 Errata</title> +<meta name="description" content="the OpenBSD CD errata page"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<link rel="stylesheet" type="text/css" href="openbsd.css"> +<link rel="canonical" href="https://www.openbsd.org/errata20.html";> + +<h2 id=OpenBSD> +<a href="index.html"> +<i>Open</i><b>BSD</b></a> +2.0 Errata +</h2> +<hr> + +For errata on a certain release, click below:<br> +<a href="errata21.html">2.1</a>, +<a href="errata22.html">2.2</a>, +<a href="errata23.html">2.3</a>, +<a href="errata24.html">2.4</a>, +<a href="errata25.html">2.5</a>, +<a href="errata26.html">2.6</a>, +<a href="errata27.html">2.7</a>, +<a href="errata28.html">2.8</a>, +<a href="errata29.html">2.9</a>, +<a href="errata30.html">3.0</a>, +<a href="errata31.html">3.1</a>, +<a href="errata32.html">3.2</a>, +<a href="errata33.html">3.3</a>, +<a href="errata34.html">3.4</a>, +<a href="errata35.html">3.5</a>, +<a href="errata36.html">3.6</a>, +<br> +<a href="errata37.html">3.7</a>, +<a href="errata38.html">3.8</a>, +<a href="errata39.html">3.9</a>, +<a href="errata40.html">4.0</a>, +<a href="errata41.html">4.1</a>, +<a href="errata42.html">4.2</a>, +<a href="errata43.html">4.3</a>, +<a href="errata44.html">4.4</a>, +<a href="errata45.html">4.5</a>, +<a href="errata46.html">4.6</a>, +<a href="errata47.html">4.7</a>, +<a href="errata48.html">4.8</a>, +<a href="errata49.html">4.9</a>, +<a href="errata50.html">5.0</a>, +<a href="errata51.html">5.1</a>, +<a href="errata52.html">5.2</a>, +<br> +<a href="errata53.html">5.3</a>, +<a href="errata54.html">5.4</a>, +<a href="errata55.html">5.5</a>, +<a href="errata56.html">5.6</a>, +<a href="errata57.html">5.7</a>, +<a href="errata58.html">5.8</a>, +<a href="errata59.html">5.9</a>, +<a href="errata60.html">6.0</a>, +<a href="errata61.html">6.1</a>, +<a href="errata62.html">6.2</a>, +<a href="errata63.html">6.3</a>, +<a href="errata64.html">6.4</a>, +<a href="errata65.html">6.5</a>, +<a href="errata66.html">6.6</a>. +<hr> + +<p> +For the OpenBSD 2.0 release, the formal process for creating and +distributing errata patches had not been developed yet. +Nevertheless, a number of security advisories do exist. + +<ul> + +<li> +<strong>SECURITY VULNERABILITY</strong> in BIND<br> +<a href="advisories/sni_01_dns.txt">Secure Networks advisory 01</a> +(November 18, 1996) +<p> + +<li> +<strong>SECURITY VULNERABILITY</strong> in Vixie cron<br> +<a href="advisories/sni_02_cron.txt">Secure Networks advisory 02</a> +(December 16, 1996) +<p> + +<li> +<strong>SECURITY VULNERABILITY</strong> in default cron jobs<br> +<a href="advisories/sni_03_cronjobs.txt">Secure Networks advisory 03</a> +(December 23, 1996) +<p> + +<li> +<strong>SECURITY VULNERABILITY</strong> related to source routing +and TCP spoofing<br> +<a href="advisories/sni_06_tcpoptions.txt">Secure Networks advisory 06</a> +(February 10, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</strong> with 4.4BSD NFS file handles<br> +<a href="advisories/sni_10_filehandles.txt">Secure Networks advisory 10</a> +(March 7, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITIES</strong> in BIND<br> +<a href="advisories/sni_12_resolverid.txt">Secure Networks advisory 12</a> +(April 22, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITIES</strong> in Kerberos V<br> +<a href="advisories/sni_13_kerberos.txt">Secure Networks advisory 13</a> +(April 29, 1997) +</ul> + +<hr> Index: errata21.html =================================================================== RCS file: /cvs/www/errata21.html,v retrieving revision 1.84 diff -u -p -r1.84 errata21.html --- errata21.html 30 Sep 2019 13:17:48 -0000 1.84 +++ errata21.html 24 Apr 2020 20:25:21 -0000 @@ -22,6 +22,7 @@ <hr> For errata on a certain release, click below:<br> +<a href="errata20.html">2.0</a>, <a href="errata22.html">2.2</a>, <a href="errata23.html">2.3</a>, <a href="errata24.html">2.4</a>, @@ -37,8 +38,8 @@ For errata on a certain release, click b <a href="errata34.html">3.4</a>, <a href="errata35.html">3.5</a>, <a href="errata36.html">3.6</a>, -<a href="errata37.html">3.7</a>, <br> +<a href="errata37.html">3.7</a>, <a href="errata38.html">3.8</a>, <a href="errata39.html">3.9</a>, <a href="errata40.html">4.0</a>, @@ -54,8 +55,8 @@ For errata on a certain release, click b <a href="errata50.html">5.0</a>, <a href="errata51.html">5.1</a>, <a href="errata52.html">5.2</a>, -<a href="errata53.html">5.3</a>, <br> +<a href="errata53.html">5.3</a>, <a href="errata54.html">5.4</a>, <a href="errata55.html">5.5</a>, <a href="errata56.html">5.6</a>, @@ -290,6 +291,37 @@ command without leading colon(s) like: </pre> <p> +<li> +<strong>SECURITY VULNERABILITY</STRONG> in 4.4BSD procfs<br> +<a href="advisories/procfs.txt">OpenBSD advisory</a> (June 24, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</STRONG> in 4.4BSD rfork<br> +<a href="advisories/rfork.txt">OpenBSD advisory</a> (August 2, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</STRONG> in vacation<br> +<a href="advisories/sni_18_vacation.txt">Secure Networks advisory 18</a> +(September 1, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</STRONG> in I/O Signal Handling<br> +<a href="advisories/signals.txt">OpenBSD advisory</a> (September 15, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</STRONG> in lpd<br> +<a href="advisories/sni_19_lpd.txt">Secure Networks advisory 19</a> +(October 2, 1997) +<p> + +<li> +<strong>SECURITY VULNERABILITY</STRONG> in tgetent<br> +<a href="advisories/sni_20_tgetent.txt">Secure Networks advisory 20</a> +(October 21, 1997) </ul> <hr> Index: errata22.html =================================================================== RCS file: /cvs/www/errata22.html,v retrieving revision 1.99 diff -u -p -r1.99 errata22.html --- errata22.html 30 Sep 2019 13:17:48 -0000 1.99 +++ errata22.html 24 Apr 2020 20:25:21 -0000 @@ -164,6 +164,8 @@ variable semantics to mean that all sour be blocked completely. <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/sourceroute.patch";> A kernel patch is provided</a>. +For more details, see the <a href="advisories/sourceroute.txt">OpenBSD +advisory</a>. <p> <li id="ruserok"> @@ -211,6 +213,7 @@ gain root trivially and/or turn securele <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/vm_mmap.patch";> A kernel patch is available which corrects this behaviour (this is revision 3 of this patch)</a>. +For more details, see the <a href="advisories/mmap.txt">OpenBSD advisory</a>. <p> <li id="build1"> Index: errata23.html =================================================================== RCS file: /cvs/www/errata23.html,v retrieving revision 1.87 diff -u -p -r1.87 errata23.html --- errata23.html 30 Sep 2019 13:17:48 -0000 1.87 +++ errata23.html 24 Apr 2020 20:25:21 -0000 @@ -121,6 +121,8 @@ Chpass(1) has a file descriptor leak whi attacker to modify /etc/master.passwd. <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.3/common/chpass.patch";> A source code patch exists which remedies this problem.</a> +For more details, see the +<a href="advisories/nai_28_chpass.txt">Network Associates advisory</a>. <p> <li id="resid"> Index: errata27.html =================================================================== RCS file: /cvs/www/errata27.html,v retrieving revision 1.97 diff -u -p -r1.97 errata27.html --- errata27.html 30 Sep 2019 13:17:48 -0000 1.97 +++ errata27.html 24 Apr 2020 20:25:22 -0000 @@ -393,6 +393,8 @@ which disables its functionality, do </pre> <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.7/common/025_pw_error.patch";> A source code patch exists which remedies this problem.</a> +For more details, see the +<a href="advisories/pw_error.txt">OpenBSD advisory</a>. <p> <li id="talkd"> Index: errata31.html =================================================================== RCS file: /cvs/www/errata31.html,v retrieving revision 1.90 diff -u -p -r1.90 errata31.html --- errata31.html 30 Sep 2019 13:17:48 -0000 1.90 +++ errata31.html 24 Apr 2020 20:25:22 -0000 @@ -231,6 +231,7 @@ system call allows an attacker to overwr code in kernel context.<br> <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/3.1/common/014_scarg.patch";> A source code patch exists which remedies this problem.</a> +For more details, see the <a href="advisories/select.txt">OpenBSD advisory</a>. <p> <li id="kerntime"> Index: advisories/res_random.txt =================================================================== RCS file: advisories/res_random.txt diff -N advisories/res_random.txt --- advisories/res_random.txt 2 Jul 2001 19:26:26 -0000 1.2 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,813 +0,0 @@ - ###### ## ## ###### - ## ### ## ## - ###### ## # ## ## - ## ## ### ## - ###### . ## ## . ######. - - Secure Networks Inc. - AND - CORE Seguridad de la Informacion - - - Security Advisory - April 22, 1997 - - BIND Vulnerabilities and Solutions - - -Problem Description -~~~~~~~~~~~~~~~~~~~ - -This advisory contains descriptions and solutions for two vulnerabilities -present in current BIND distributions. These vulnerabilities are actively -being exploited on the Internet. - -I. The usage of predictable IDs in queries and recursed queries allows for - remote cache corruption. This allows malicious users to alter domain - name server caches to change the addresses and hostnames of hosts on the - internet. - -II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in - size. This results in potential buffer overflows in programs which - expect the BIND resolver to only return a maximum hostname length of - MAXHOSTNAMELEN. - - - - Problem I. The usage of predictable ID's - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - -Problem I. - Impact -~~~~~~~~~~~~~~~~~~~ - -Remote root users can poison BIND and Microsoft Windows NT name server -caches by forging UDP packets. We should note that unlike other well -documented attacks, in this instance it is NOT necessary for the attacker -to take over a DNS server or sniff the target network. - - -Problem I. - Technical Details -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This particular cache corruption attack requires that the target nameserver -be configured to allow recursion. Recursion allows a nameserver to handle -requests for zones or domains which it does not serve. When receiving a -query for a zone or domain which is not served by the name server, the name -server will transmit a query to a nameserver which serves the desired -domain. Once a response is received from the second nameserver, the first -nameserver sends the response back to the requesting party. - -The following attack is outlined in the paper "Addressing weaknesses in the -Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. -To the extent of our knowledge, this problem has not been previously -addressed. The paper also assumes that the attacker has super-user access -to a primary nameserver, here we demonstrate that this is not necessary nor -are source routed packets required. - -Using the recursion feature, one can poison the cache on a name server with -the following procedure: - - -Problem I. - The Players -~~~~~~~~~~~~~~~~~~~~~~~~ - -. HOST.ATTACKER.COM is the attacking host. - -. DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is - the only name server for ATTACKER.COM to simplify the description. - -. DNS.TARGET.COM is the target nameserver which runs BIND. What we will - attempt to do is add an A (address) resource record on DNS.TARGET.COM - that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that - WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. - -. DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have - determined this before the attack begins. Once again we just presume - its the only one in order to simplify this description. - - -Problem I. - The Attack -~~~~~~~~~~~~~~~~~~~~~~~ - -A. First a query is sent to DNS.TARGET.COM asking for the address of - UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, - meaning that if the nameserver we are querying has recursion enabled, - it will query another nameserver with our query (assuming it does not - have the information cached). - -B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM - domain, then it will build a query packet and send it to - DNS.ATTACKER.COM. - -C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet - sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine - the query ID (qid0) used by DNS.TARGET.COM. Chances are that the - next queries generated by DNS.TARGET.COM will have query IDs that will - fall in the range [qid0,qid0+N] where N is dependent on the amount of - queries DNS.TARGET.COM is generating in the period of time on which the - attack takes place. N is usually <= 10 for most cases. - -D. Once we have determined what the next query ID generated will be, we - send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. - -E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, - telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. - -F. If we guessed the query ID used by DNS.TARGET.COM in its recursed - query and our response is received first, our response will be taken - as valid and the address will be cached. Subsequent responses will - be discarded as duplicates. We can always send many (N*M) spoofed - packets with different IDs in the range (qid0,qid0+N] so we will be - sure that at least one of them will hit DNS.TARGET.COM and have the - 'right' ID. M is a factor dependent of the amount of UDP packets we - expect to lose on their way to DNS.TARGET.COM. - - -Problem I. - The Result -~~~~~~~~~~~~~~~~~~~~~~~ - -If the attack succeeded, any query to DNS.TARGET.COM asking for -WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, -any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to -contact WWW.SPOOFED.COM. - -The usage of 127.0.0.1 in this description is of course for instructional -purposes, any IP address can be used, in particular an attacker could use -its own IP address (BADGUY.COM's IP) so all connections to 'host' will go -to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given -this attack, it is easy to visualize the effects of impersonating a high -traffic FTP distribution site. This attack can also be used to intercept -email traffic, and bypass address based authentication methods, including -TCP wrappers and firewalls. - - -Problem I. - Notes -~~~~~~~~~~~~~~~~~~ - -This attack depends on a few things to succeed: - -1. The attacker has complete control of DNS.ATTACKER.COM's network, - he can both spoof and sniff DNS packets there. In particular, he can - sniff DNS packets sent to DNS.ATTACKER.COM. - -2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must - be received before the legit response from DNS.SPOOFED.COM. This is - very easy to achieve. In testing we have not yet encountered a situation - where we could not get our packets to the nameserver first. - -3. The name server on DNS.TARGET.COM supports recursion and caches - responses. This is common practice. It should be noted that most - nameservers allow recursion (unless specifically denied by - configuration options). Root name servers, however, do not allow - recursion. - - If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial - of service attack can be performed, in this case, spoofed responses sent - by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not - exist (and be authorative on this). - - The existence of several nameservers for the domains does not alter the - basic outline of this attack. The attacker would only need to send DNS - responses with source addresses of each of SPOOFED.COM's nameservers. - (N*M*I responses, where I is the number of nameservers). - - -Problem I. - Systems Affected -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- - All systems using BIND as their domain name server with recursion - enabled. - -- - Windows NT (server) version 3.51 & 4.0 DNS server. - Microsoft has been notified and has acknowledged this is a serious - problem. No information on a fix is available. - - - - Problem II. Hostname length checking - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - -Problem II. - Impact -~~~~~~~~~~~~~~~~~~~~ - -BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to -programs. As many programs utilize buffers of size MAXHOSTNAMELEN and -copy the results from a query into these buffers, an overflow can occur. -This can allow an attacker to execute arbitrary commands on a remote -server in a worst case scenario. - - -Problem II. - Systems Affected -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All systems running BIND. - - -Fix Information -~~~~~~~~~~~~~~~ - -Obtain BIND version 4.9.5-P1. BIND is available from ftp.isc.org in -the directory /isc/bind/src. Patches to solve both problem I and -problem II are included at the end of this advisory. Once BIND -has been obtained, follow the following procedure: - -i. First remove the patches from this text. This can be performed by - removing all text in between the "CUT HERE" lines, and saving it - to a text file (i.e. /tmp/diffs.txt). - -ii. Perform the following operations to apply the patches: - -% gzip -d bind.tar.gz -% mkdir bind -% cd bind -% tar -xvf ../bind.tar -% patch < /tmp/diffs.txt - -iii. Rebuild BIND - - -Attributions -~~~~~~~~~~~~ - - Ivan Arce <[email protected]> - Emiliano Kargieman <[email protected]> - - The OpenBSD Project - Who found a good solution to problem, developed a solution and - performed various tests to ensure its correctness. Individuals - involved in this effort were: - - Theo de Raadt <[email protected]> - Niels Provos <[email protected]> - Todd Miller <[email protected]> - Allen Briggs <[email protected]> - - Further attributions: - AUSCERT <[email protected]> - David Sacerdote <[email protected]> - Oliver Friedrichs <[email protected]> - Alfred Huger <[email protected]> - - -Additional Information: -~~~~~~~~~~~~~~~~~~~~~~~ - - [1] Vixie P. , "DNS and BIND security issues". - This was originally published in the proceedings of the - 5th USENIX Security Symposium and its included in the BIND - distribution under the doc/misc directory. - - [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. - "RFC1536: Common DNS implementation errors and suggested fixes" - - Refer to problem 2 for a description of other weaknesses previously - found in the recursion scheme. - - [3] Lottor, M., "RFC1033: Domain administrators operations guide" - [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" - [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and -specification" - - [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the - Domain Name System Protocol", COAST Laboratory, Department of Computer - Science, Purdue University. - - Comments and questions regarding this advisory can be sent to: - - Ivan Arce <[email protected]> - Emiliano Kargieman <[email protected]> - - For more information about CORE S.A. contact: [email protected] - - Or visit: http://www.secnet.com/core - - Encrypted mail can also be sent to <[email protected]> encrypted with - the following PGP key: - -Type Bits/KeyID Date User ID -pub 1024/9E55000D 1997/01/13 Secure Networks Inc. <[email protected]> - Secure Networks <[email protected]> - -- -----BEGIN PGP PUBLIC KEY BLOCK----- -Version: 2.6.3ia - -mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 -uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa -rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR -tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd -EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz -ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU -uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J -AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz -9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj -HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha -OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B -fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY -FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA -8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l -dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA -X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s -cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O -gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq -aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 -ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV -ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt -UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl -OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL -FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 -=DchE -- -----END PGP PUBLIC KEY BLOCK----- - - -Copyright Notice -~~~~~~~~~~~~~~~~ -The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and -CORE Seguridad de la Informacion S.A., and may be distributed freely provided -that no fee is charged for distribution, and that proper credit is given. - - You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers - and advisories at ftp://ftp.secnet.com/advisories - - You can browse our web site at http://www.secnet.com - - You can subscribe to our security advisory mailing list by sending mail to - [email protected] with the line "subscribe sni-advisories" - - -Patches -~~~~~~~ - - --- CUT HERE --- - -diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c -*** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 -- --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 -*************** -*** 537,543 **** - _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ - - /* initialize packet id */ -! _res.id = getpid() & 0x7fff; - - /* save new defaults */ - new_res = _res; -- --- 537,543 ---- - _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ - - /* initialize packet id */ -! _res.id = res_randomid(); - - /* save new defaults */ - new_res = _res; -diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c -*** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 -- --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 -*************** -*** 1658,1668 **** - } - - /* -! * These are here in case we ever want to get more clever, like perhaps -! * using a bitmap to keep track of outstanding queries and a random -! * allocation scheme to make it a little harder to predict them. Note -! * that the resolver will need the same protection so the cleverness -! * should be put there rather than here; this is just an interface layer. - */ - - void -- --- 1658,1668 ---- - } - - /* -! * This just an interface layer to the random number generator -! * used in the resolver. -! * A special random number generator is used to create non predictable -! * and non repeating ids over a long period. It also avoids reuse -! * by switching between two distinct number cycles. - */ - - void -*************** -*** 1674,1683 **** - u_int16_t - nsid_next() - { -! if (nsid_state == 65535) -! nsid_state = 0; -! else -! nsid_state++; - return (nsid_state); - } - -- --- 1674,1680 ---- - u_int16_t - nsid_next() - { -! nsid_state = res_randomid(); - return (nsid_state); - } - -diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile -*** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 -- --- ./res/Makefile Wed Apr 9 00:32:13 1997 -*************** -*** 77,89 **** - res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ - getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ - gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ -! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c - - OBJS= base64.o herror.o res_debug.o res_data.o \ - res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ - getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ - gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ -! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o - - all: libresolv.a - -- --- 77,91 ---- - res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ - getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ - gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ -! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ -! res_random.c - - OBJS= base64.o herror.o res_debug.o res_data.o \ - res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ - getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ - gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ -! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ -! res_random.o - - all: libresolv.a - -diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c -*** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 -- --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 -*************** -*** 98,103 **** -- --- 98,105 ---- - - dn = exp_dn; - cp = comp_dn; -+ if (length > MAXHOSTNAMELEN-1) -+ length = MAXHOSTNAMELEN-1; - eom = exp_dn + length; - /* - * fetch next label in domain name -diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c -*** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 -- --- ./res/res_init.c Wed Apr 9 00:33:30 1997 -*************** -*** 197,209 **** - if (!(_res.options & RES_INIT)) - _res.options = RES_DEFAULT; - -- - /* -- - * This one used to initialize implicitly to zero, so unless the app -- - * has set it to something in particular, we can randomize it now. -- - */ -- - if (!_res.id) -- - _res.id = res_randomid(); -- - - #ifdef USELOOPBACK - _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); - #else -- --- 197,202 ---- -*************** -*** 644,655 **** - return(0); /* if not using DNS configuration from NetInfo */ - } - #endif /* NeXT */ -- - -- - u_int -- - res_randomid() -- - { -- - struct timeval now; -- - -- - gettimeofday(&now, NULL); -- - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); -- - } -- --- 637,639 ---- -diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c -*** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 -- --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 -*************** -*** 107,118 **** - #endif - /* - * Initialize header fields. - */ - if ((buf == NULL) || (buflen < HFIXEDSZ)) - return (-1); - bzero(buf, HFIXEDSZ); - hp = (HEADER *) buf; -! hp->id = htons(++_res.id); - hp->opcode = op; - hp->rd = (_res.options & RES_RECURSE) != 0; - hp->rcode = NOERROR; -- --- 107,123 ---- - #endif - /* - * Initialize header fields. -+ * -+ * A special random number generator is used to create non predictable -+ * and non repeating ids over a long period. It also avoids reuse -+ * by switching between two distinct number cycles. - */ -+ - if ((buf == NULL) || (buflen < HFIXEDSZ)) - return (-1); - bzero(buf, HFIXEDSZ); - hp = (HEADER *) buf; -! hp->id = htons(_res.id=res_randomid()); - hp->opcode = op; - hp->rd = (_res.options & RES_RECURSE) != 0; - hp->rcode = NOERROR; -diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c -*** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 -- --- ./res/res_random.c Tue Apr 22 02:31:25 1997 -*************** -*** 0 **** -- --- 1,262 ---- -+ /* $OpenBSD: res_random.txt,v 1.2 2001/07/02 19:26:26 jufi Exp $ */ -+ -+ /* -+ * Copyright 1997 Niels Provos <[email protected]> -+ * All rights reserved. -+ * -+ * Theo de Raadt <[email protected]> came up with the idea of using -+ * such a mathematical system to generate more random (yet non-repeating) -+ * ids to solve the resolver/named problem. But Niels designed the -+ * actual system based on the constraints. -+ * -+ * Redistribution and use in source and binary forms, with or without -+ * modification, are permitted provided that the following conditions -+ * are met: -+ * 1. Redistributions of source code must retain the above copyright -+ * notice, this list of conditions and the following disclaimer. -+ * 2. Redistributions in binary form must reproduce the above copyright -+ * notice, this list of conditions and the following disclaimer in the -+ * documentation and/or other materials provided with the distribution. -+ * 3. All advertising materials mentioning features or use of this software -+ * must display the following acknowledgement: -+ * This product includes software developed by Niels Provos. -+ * 4. The name of the author may not be used to endorse or promote products -+ * derived from this software without specific prior written permission. -+ * -+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR -+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. -+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, -+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT -+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF -+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -+ */ -+ -+ /* -+ * seed = random 15bit -+ * n = prime, g0 = generator to n, -+ * j = random so that gcd(j,n-1) == 1 -+ * g = g0^j mod n will be a generator again. -+ * -+ * X[0] = random seed. -+ * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator -+ * with a = 7^(even random) mod m, -+ * b = random with gcd(b,m) == 1 -+ * m = 31104 and a maximal period of m-1. -+ * -+ * The transaction id is determined by: -+ * id[n] = seed xor (g^X[n] mod n) -+ * -+ * Effectivly the id is restricted to the lower 15 bits, thus -+ * yielding two different cycles by toggling the msb on and off. -+ * This avoids reuse issues caused by reseeding. -+ * -+ * The 16 bit space is very small and brute force attempts are -+ * entirly feasible, we skip a random number of transaction ids -+ * so that an attacker will not get sequential ids. -+ */ -+ -+ #include <sys/types.h> -+ #include <netinet/in.h> -+ #include <sys/time.h> -+ #include <resolv.h> -+ -+ #if defined(BSD) && (BSD >= 199103) -+ # include <unistd.h> -+ # include <stdlib.h> -+ # include <string.h> -+ #else -+ # include "../conf/portability.h" -+ #endif -+ -+ #define RU_OUT 180 /* Time after wich will be reseeded */ -+ #define RU_MAX 30000 /* Uniq cycle, avoid blackjack -prediction */ -+ #define RU_GEN 2 /* Starting generator */ -+ #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ -+ #define RU_AGEN 7 /* determine ru_a as -RU_AGEN^(2*rand) */ -+ #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ -+ -+ #define PFAC_N 3 -+ const static u_int16_t pfacts[PFAC_N] = { -+ 2, -+ 3, -+ 2729 -+ }; -+ -+ static u_int16_t ru_x; -+ static u_int16_t ru_seed; -+ static u_int16_t ru_a, ru_b; -+ static u_int16_t ru_g; -+ static u_int16_t ru_counter = 0; -+ static u_int16_t ru_msb = 0; -+ static long ru_reseed; -+ static u_int32_t tmp; /* Storage for unused random */ -+ static struct timeval tv; -+ -+ static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); -+ static void res_initid __P((void)); -+ -+ #ifndef __OpenBSD__ -+ /* -+ * No solid source of strong random in the system. Sigh. Fake it. -+ */ -+ u_long -+ arc4random() -+ { -+ static char state[256]; -+ char *savestate; -+ char *setstate(); -+ static unsigned seed; -+ static int count; -+ u_long datum; -+ -+ if (++count == 129837 || seed == 0) { -+ struct timeval tv; -+ -+ count = 0; -+ gettimeofday(&tv, NULL); -+ seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; -+ initstate(seed, state, sizeof state); -+ } -+ savestate = setstate(state); -+ datum = random(); -+ setstate(savestate); -+ return (datum); -+ } -+ -+ #endif -+ -+ /* -+ * Do a fast modular exponation, returned value will be in the range -+ * of 0 - (mod-1) -+ */ -+ -+ static u_int32_t -+ pmod(gen, exp, mod) -+ u_int32_t gen, exp, mod; -+ { -+ u_int32_t s, t, u; -+ -+ s = 1; -+ t = gen; -+ u = exp; -+ -+ while (u) { -+ if (u & 1) -+ s = (s*t) % mod; -+ u >>= 1; -+ t = (t*t) % mod; -+ } -+ return (s); -+ } -+ -+ /* -+ * Initalizes the seed and chooses a suitable generator. Also toggles -+ * the msb flag. The msb flag is used to generate two distinct -+ * cycles of random numbers and thus avoiding reuse of ids. -+ * -+ * This function is called from res_randomid() when needed, an -+ * application does not have to worry about it. -+ */ -+ static void -+ res_initid() -+ { -+ u_int16_t j, i; -+ int noprime = 1; -+ -+ tmp = arc4random(); -+ ru_x = (tmp & 0xFFFF) % RU_M; -+ -+ /* 15 bits of random seed */ -+ ru_seed = (tmp >> 16) & 0x7FFF; -+ -+ tmp = arc4random(); -+ -+ /* Determine the LCG we use */ -+ ru_b = (tmp & 0xfffe) | 1; -+ ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); -+ while (ru_b % 3 == 0) -+ ru_b += 2; -+ -+ tmp = arc4random(); -+ j = tmp % RU_N; -+ tmp = tmp >> 16; -+ -+ /* -+ * Do a fast gcd(j,RU_N-1), so we can find a j with -+ * gcd(j, RU_N-1) == 1, giving a new generator for -+ * RU_GEN^j mod RU_N -+ */ -+ -+ while (noprime) { -+ for (i=0; i<PFAC_N; i++) -+ if (j%pfacts[i] == 0) -+ break; -+ -+ if (i>=PFAC_N) -+ noprime = 0; -+ else -+ j = (j+1) % RU_N; -+ } -+ -+ ru_g = pmod(RU_GEN,j,RU_N); -+ ru_counter = 0; -+ -+ gettimeofday(&tv, NULL); -+ ru_reseed = tv.tv_sec + RU_OUT; -+ ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; -+ } -+ -+ u_int -+ res_randomid() -+ { -+ int i, n; -+ -+ gettimeofday(&tv, NULL); -+ if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) -+ res_initid(); -+ -+ if (!tmp) -+ tmp = arc4random(); -+ -+ /* Skip a random number of ids */ -+ n = tmp & 0x2f; tmp = tmp >> 6; -+ if (ru_counter + n >= RU_MAX) -+ res_initid(); -+ -+ for (i=0; i<=n; i++) -+ /* Linear Congruential Generator */ -+ ru_x = (ru_a*ru_x + ru_b) % RU_M; -+ -+ ru_counter += i; -+ -+ return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; -+ } -+ -+ #if 0 -+ void -+ main(int argc, char **argv) -+ { -+ int i, n; -+ u_int16_t wert; -+ -+ res_initid(); -+ -+ printf("Generator: %d\n", ru_g); -+ printf("Seed: %d\n", ru_seed); -+ printf("Reseed at %ld\n", ru_reseed); -+ printf("Ru_X: %d\n", ru_x); -+ printf("Ru_A: %d\n", ru_a); -+ printf("Ru_B: %d\n", ru_b); -+ -+ n = atoi(argv[1]); -+ for (i=0;i<n;i++) { -+ wert = res_randomid(); -+ printf("%06d\n", wert); -+ } -+ } -+ #endif -+ - - --- CUT HERE --- - ------BEGIN PGP SIGNATURE----- -Version: 2.6.3ia -Charset: noconv - -iQCVAwUBM1ygQLgIhFKeVQANAQHhvwQAgm9c8ai94FzE03dZ3S8HQmpiZXDB4cGU -EqZYu32tV7a/eHT/fyw01uMXpeLIaZERQNGTJokwpZKbCUAY67ZzsOGYqp5Ja+To -YN3WMD1pXHPEC5+vq+r94chX0zobvjPrd3Rhg1PHxEcrkMjsliiYPNnTrotOMrUy -NHiFI/kbY0Q= -=vf1T ------END PGP SIGNATURE----- - ---[0124]-- Index: advisories/sni_12_resolverid.txt =================================================================== RCS file: /cvs/www/advisories/sni_12_resolverid.txt,v retrieving revision 1.2 diff -u -p -r1.2 sni_12_resolverid.txt --- advisories/sni_12_resolverid.txt 2 Jul 2001 19:26:27 -0000 1.2 +++ advisories/sni_12_resolverid.txt 24 Apr 2020 20:25:22 -0000 @@ -422,16 +422,32 @@ diff -cNr ../bind-4.9.5-P1-rel/res/Makef - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** - res_comp.c res_init.c res_mkquery.c res_query.c res_send.c getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c - - OBJS= base64.o herror.o res_debug.o res_data.o res_comp.o res_init.o res_mkquery.o res_query.o res_send.o getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o + res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ + getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ + gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ +! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c + + OBJS= base64.o herror.o res_debug.o res_data.o \ + res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ + getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ + gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ +! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- - res_comp.c res_init.c res_mkquery.c res_query.c res_send.c getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c ! res_random.c - - OBJS= base64.o herror.o res_debug.o res_data.o res_comp.o res_init.o res_mkquery.o res_query.o res_send.o getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o ! res_random.o + res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ + getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ + gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ +! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ +! res_random.c + + OBJS= base64.o herror.o res_debug.o res_data.o \ + res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ + getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ + gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ +! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ +! res_random.o all: libresolv.a @@ -800,5 +816,4 @@ NHiFI/kbY0Q= =vf1T -----END PGP SIGNATURE----- - - +--[0124]--
