From: SMTP%"everhart@mail09.mitre.org" 22-JAN-1998 17:25:34.00 To: everhart@gce.com (everhart@gce.com) CC: Subj: FWD: Re: possible port number solution? --===_tgate3_43940_96622513_=== Content-Type: text/plain; charset="us-ascii" ----- Forwarded message follows ----- References: <5CEA8663F24DD111A96100805FFE6587031E38AC@red-msg-51.dns.microsoft.com> Date: Tue, 20 Jan 98 22:00:22 -0500 Reply-To: Common Internet File System From: Andrew Tridgell Subject: Re: possible port number solution? To: In-Reply-To: <5CEA8663F24DD111A96100805FFE6587031E38AC@red-msg-51.dns.microsoft.com> (message from Paul Leach on Tue, 20 Jan 1998 17:41:38 -0800) > I'm saying that if there are 10 reasons NOT to do > net use x: \\cifs.badguys.com > then an 11th one doesn't matter. Or, more precisely, there are 10 > preconditions for safely accessing a server, then adding an 11th isn't a > problem -- unless _all_ 10 or 11 preconditions are true, you don't access > the server. we are not talking about cifs.badguys.com here. We are talking about organisations normal file servers. "my.local.server" if you like. A ordinary user logged into an organisations server can serve up any binaries he likes if that server has not yet been upgraded. > I.e., you shouldn't access a server on a low port unless you trust the > administrator. You shouldn't access a server on a high port unless you trust > the administrator and *know* that the high port has been secured. In both > cases, you are NOT safe if you blindly access the server knowing nothing > about it. If both cases, you have to *know* something in advance about the > server in order to be safe. The extra amount that you have to know for a > high numbered port is trivial, and the extra work that the admin has to go > to to make it secure is trivial and well understood as a result of NFS. So now security is the end-users responsibility? Users need to think "gee, I better not use this NT5 client to access an NT4 server, because I read somewhere that it might be insecure". Users won't be "blindly accessing servers knowing nothing about it". They will be accessing their normal server that they have accessed for years. Only now they they have upgraded to NT5 workstation they are suddenly insecure. > So don't access a server unless you *know* that the admin has reserved 3020. > It will also happen even with a low numbered port with NT4 and Windows 95. We were told at the first CIFS conference that 70% of all Windows users that consider themselves expert users have never made a directory. Now you expect them to know about TCP port numbers? Even if they did know, you aren't giving them a very nice choice. Either don't access old servers or put up with a security hole. > We do NOT in general let random users install and run software on servers. so you don't give them logins? Running a program does not require special privileges. Anyone can copy an executable to their home directory and run it. Are you going to tell the whole world that multi-user systems are no longer recommended? > > > 3. who is competent enough that these programs are unable to replace any > > > binaries on the shares that client might fetch and run (despite not > > being > > > competent enough to prevent them from using 3020), > > > > which is the default if normal installation procedures are > > followed. > > > Sorry, I don't understand. Which defaults on which system? if an admin installs some software on a NTFS partition then by default the executables will not be writeable by all users. > No. This is just ONE way to assure safety when accessing a server. There are > others. there were others. Now there is one less. The one you are removing is the only one available on many current systems. > > And how do you > > handle password-less read-only shares? > > > Only acess them if the server is *known* to be secure. by "secure" you now mean that only admin users can login? Are you seriously suggesting that guest shares can now never be exported safely from multi-user systems? > How is the server started by a malicious user going to be able to change (or > even read) the real files on the server -- the user has no access to those > files (if the server's local security is any good). The most it can do is > serve up bogus (or trojan) versions of files I ask for, and deny me access > to the real ones. more security falicies! 1) refer to the exploit for how the malicios user can guarantee access to the files. 2) you are equating read-only with no-access. Binaries and documents are generally installed read-only but with world read permissions. Being able to read a executable on a server is harmless. Being able to modify what executable clienst receive is dangerous. > > and just in case it hasn't been, lets make it even easier by putting > > it on a high port number. That makes the only current defence against > > hijacking of SMB (a full port block) unacceptable for firewall admins > > so they'll have to use a SYN block. That will make hijacking much > > easier for everyone. > > > Totally bogus. Packets from the hijacker look just like packets from the > real user, so NO firewall can prevent hijacking. To prevent hijacking with a firewall just block the port completely. That is what large numbers of sites do right now. My point is that by moving the port above 1024 you give firewall admins a difficult choice. Either they randomly disrupt some existing services or they leave themselves open to hijacking. Hijacking is, however, only a very minor part of all the problems associated with this proposed protocol change. It is just one more thing for admins to worry about. > I didn't say it was bad. I said it had very little value, and was not > adequate to guarantee security. Only mutual authentication and integrity > protection on all messages is. so, propose a method of giving us mutual authentication and integrity protection. One that works within existing security frameworks and for all types of shares. It is not a trivial thing to add. SMB packet signing does not solve the problems. Removing the only existing protections without replacing them with something else is silly. > > Paul, what the heck is going on here? I know you know more about > > security than this. > > > And that's why I know that low ports, like .rhosts, is a bogus thing to rely > on for security. It is bogus for client authentication, but there is a lot more to security than authentication! > If I trusted him, why couldn't I have trusted him to start a robust server > on the high numbered port? Until I *know* that he has done so, I shouldn't > access the server. two problems here 1) "robust server". Now what was a DOS attack becomes a security breach as soon as someone finds a way to make the smb daemon on some system exit. 2) "until". "until" has already happened. Users right now trust their servers. They install a new Microsoft client. Suddenly they can't trust the servers any more. The servers admin has done nothing yet his server can now be subverted. All thanks to a port number change proposed by you. > One should indeed say "CIFS uses a high numbered port, secure it and use it > with the same care as you do NFS". > > > This problem *will* generate a CERT advisory if you go ahead. > > > Did NFS? 1) The NFS people haven't been stupid enough to *change* their port number. For NT systems the issue is that *any* port number change is bad. Just try proposing to the NFS people that they move the port number to something else. Even better, try to get the portmapper port (111) moved. You will meet the same resistance. 2) yes, NFS port number problems have generated security advisories. Look for the "bind() Security Problems" in the Best of Security archives. > > > It's bad policy to run unsigned executables from _any_server that allows > > > arbitrary (possibly malicious) users to run arbitrary programs. > > > > you are talking about a huge proportion of your customers here! How > > many of your customers use signed executables? > > > Very few within the LAN; lots of them over the Internet, because they use > IE, and it checks signatures. The problem of someone with login access setting up a nasty proxy is mostly a LAN problem. It also applies to WAN servers but the LAN environment is where it has the most impact. > Logins to the server are OK -- that won't let the user run a program, or > tamper with binaries or documents other than his own. Very few of our > customers' servers allow users to login in and run binaries of their own > choosing. what??? 1) If you create a user on a NT4 box then they can login and run programs. That is how I tested the exploit. I created a new user with default permission (in the "Users" group only) and that user installed and ran Perl. I've never plumbed the depths of NT options so there may be a way to stop users running their own programs but it certainly ain't the default. Even if it is possible you will now be equating "can run a program" with "can compromise security". That is *not* good. 2) they don't need to tamper with other peoples binaries and documents. They just run that little proxy exploit that does it for them. > Look - if it was possible to just get IANA to give me a low numbered port, I > would. You said earlier that you didn't try because they said "give us a good reason". You are very easily scared off. It won't be worth trying till you find a way to address the problem on NT anyway. A low port number will solve the problem for unix systems but not for existing NT servers. Let's leave the damn port number where it is. You might find it acceptable to wreck your customers security but others will not. Andrew ---------------------------------------------------------------- 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_43940_96622513_===-- ================== RFC 822 Headers ================== Return-Path: everhart@mail09.mitre.org Received: by norlmn.gce.com (UCX X4.2-14, OpenVMS E7.1-1H1 Alpha); Thu, 22 Jan 1998 17:16:27 -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 HAA19052 for ; Thu, 22 Jan 1998 07:39:08 -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 HAA25424 for ; Thu, 22 Jan 1998 07:42:45 -0500 (EST) Received: from mail09.mitre.org (unverified [129.83.20.43]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 22 Jan 1998 07:35:14 -0500 Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA14714; Thu, 22 Jan 1998 07:35:09 -0500 Subject: FWD: Re: possible port number solution? From: everhart@mail09.mitre.org (Glenn C. Everhart) To: everhart@gce.com (everhart@gce.com) Message-Id: <980122073508.31233@mail09.mitre.org.0> Date: Thu, 22 Jan 98 07:35:09 -0500 X-Mailer: MailWorks 2.0-4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_tgate3_43940_96622513_==="