From: SMTP%"everhart@mail09.mitre.org" 23-JAN-1998 13:09:35.81 To: everhart@gce.com (everhart@gce.com) CC: Subj: FWD: Re: possible port number solution? (smb crash) --===_tgate3_58862_96709784_=== Content-Type: text/plain; charset="us-ascii" ----- Forwarded message follows ----- Date: Thu, 22 Jan 98 23:51:41 -0500 Reply-To: Common Internet File System From: Paul Leach Subject: Re: possible port number solution? To: > ---------- > From: Andrew Tridgell[SMTP:tridge@SAMBA.ANU.EDU.AU] > Reply To: Common Internet File System > Sent: Thursday, January 22, 1998 7:30 PM > To: CIFS@DISCUSS.MICROSOFT.COM > Subject: Re: possible port number solution? > > Paul wrote: > > I meant to say that the reason they would continue to block it even > > if SMB on 139 were bullet-proof is because of the other ones. I just > > posted the list of a couple dozen of other services whose protocols > > use 139 via different NetBIOS name suffixes. > > Ok, and you suggested that if someone tried to send random data to > these other protocols then a blue screen would result. > > I've now written a simple little program to test this idea. It opens > random connections to netbios protocol numbers between 0 and 255 then, > if the session is not rejected, it sends a packet of random data of > random length (maximum 8k). > > The program has now been running for about 30 minutes on my Linux box, > pointed at my NT4 server (the version that was given out at the first > CIFS conference). So far the only session requests that have been > accepted by NT4 are on protocol numbers 0x3 and 0x20, which is > probably what is expected. No blue screen has resulted. I'll leave it > running overnight. > Which means that you aren't running any of those other services listed in the message I posted. > Maybe NT4 is more robust than you think! > That would certainly be nice. > I also think that if any "blue screens" were discovered in this way > then the correct fix would be to fix those security holes. Moving the > port number and relying on everyone keeping up their port 139 > firewalls seems like an inadequate response to a problem that you seem > to think NT has. > Actually, I wouldn't say that I think that NT has a problem; what I don't know is that it _doesn't_ have a problem. And I don't think that its a good general design philospphy to have to secure a whole bunch of protocols just oin order to safely use one. > > So, leaving it on 139 doesn't solve the problem of the other protocols > that > > use 139. And if we can't figure out a solution to the problems that > result > > from moving it, then it sounds like a rock and a hard place to me. > > I'm at least pleased to hear you agree that changing the port number > is a "rock" (or is it a "hard place" ?). That means we have made some > progress in convincing you that there is a problem with the proposal! > You've convinced me that there is a problem with adding a new port for a service and transparently having clients try that port first. You haven't convinced me that in general there's any major value to privileged ports. Real security depends on strong authentication and on mechanisms like Zones to keep clients away from unsafe servers (even ones that can authenticate). If you have those, then privileged ports aren't needed. They might be a useful way to multiplex a single computer, but they aren't necessary for security, and I think there are better ways to multiplex a server. (We're going to run out of privileged ports.) > If the real problem is these "other protocols" then surely the correct > solution is to fix them? > It's one way. I think the better way is to decouple them. To use an analogy, you would never propose that FTP, HTTP, Telnet, NFS, NTP, SMTP, IMAP, and POP3 all use one port, would you? -- that would mean that all of them would have to be secure before any of them could be let through a firewall. There's just no reason to cascade the risks -- it's better to make them separable. > You will need to do that anyway as you don't > want to rely on people blocking the port number. > I don't see anything wrong with that. As you said, there are two kinds of firewall admins. The conservative kind will block SMB until its proven safe. But, no matter what we also have to make SMB safe. The other kind will let it through until its proven unsafe. But it'll be safe. > My little experiment with random netbios protocols seems to indicate > that fixing these other protocols is not such a mammoth task as you > might think. There might, in fact, be nothing to fix. > Well, 20 is SMB, and the test hasn't found the hole we know is there that was recently reported. In general, you are quite unlikely to get past the first message of a multi-message session, so problems in sunbsequent messages will never get noticed. I.e., you probably will never generate a legal NegProt, so as long as NegProt handling is robust, you'll never get to see if SessionSetupAndX with bad parameters crashes. Paul ---------------------------------------------------------------- Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://discuss.microsoft.com/archives/index.html ----- End of forwarded message ----- --===_tgate3_58862_96709784_===-- ================== RFC 822 Headers ================== Return-Path: everhart@mail09.mitre.org Received: by norlmn.gce.com (UCX X4.2-14, OpenVMS E7.1-1H1 Alpha); Fri, 23 Jan 1998 13:07:13 -0500 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id HAA06789 for ; Fri, 23 Jan 1998 07:45:59 -0500 (EST) Received: from TGATE3 (tgate3.mitre.org [129.83.20.27]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id HAA25412 for ; Fri, 23 Jan 1998 07:49:46 -0500 (EST) Received: from mail09.mitre.org (unverified [129.83.20.43]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 23 Jan 1998 07:49:44 -0500 Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA21740; Fri, 23 Jan 1998 07:49:40 -0500 Subject: FWD: Re: possible port number solution? (smb crash) From: everhart@mail09.mitre.org (Glenn C. Everhart) To: everhart@gce.com (everhart@gce.com) Message-Id: <980123074939.31233@mail09.mitre.org.0> Date: Fri, 23 Jan 98 07:49:39 -0500 X-Mailer: MailWorks 2.0-4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_tgate3_58862_96709784_==="