Re: [Full-Disclosure] Gates: 'You don't need perfect code' for good security

From: Geoincidents (geoincidents_at_getinfo.org)
Date: 11/03/03

  • Next message: Kristian Hermansen: "[Full-Disclosure] Buffer Underflow in popular CD-Writing Sotware" 
    To: "Full Disclosure" <full-disclosure@lists.netsys.com>
Date: Sun, 2 Nov 2003 19:01:19 -0500

    > However, the original poster's point was on patch management -- MS has had
    > as many bugs as the competing distributions, not really fewer. I was
    simply
    > pointing out the fact that MS had many fewer bulletins to counter those
    who
    > say things like "MS releases big patches", etc.

    I don't disagree with your reasoning here. I happen to think MS has been
    doing well with patch management software (it's required for survival when
    your geared for ease of use though) but I still take them to task for the
    half assed way they do it sometimes. For example it took Russ from NTbugtraq
    to get them to fix windowsupdate so it checked files instead of registry
    entries for some of the patches. (thank you Russ!) I actually see some hope
    for windowsupdate now. (it's still making mistakes but it's improved from 5
    months ago)

    > You're on target about NTMail, but might I suggest that NTMail is a
    > lower-profile product than either Exchange *or* Sendmail? I compared it
    to
    > Sendmail because it had (easily) matching market share.

    Fair enough, but my viewpoint is from the perspective of a person who has
    literally spent years hacking it and dealing with spammers and everyone else
    on the internet trying to hack it and 20+K users pumping mail thru it 24x7.
    The only real point you might make is that Exchange is more than just a mail
    server, but then windows is more than just a tcp/ip platform and that
    doesn't seem to matter when we talk about security so..

    >Really, the
    > problem isn't that people need to be held responsible for mistakes, it's
    > that testing and feedback needs to come from greater audiences to
    eliminate
    > bugs and unnecessarily insecure design / config.

    Now here is an area where we are in violent agreement. It's (security) not
    in the code so much as in the design and default config. It's painfully
    obvious to me that there are product groups within MS for whom security is
    but a passing afterthought. Other groups within MS seem to have it as one of
    their main design features that need to be addressed before the first line
    of code is written.

    > Unfortunately, the
    > developers of these projects have not really come up with an effective
    > method of simulating a strong variety of test environments, short of
    > full-blown releases. The result is that the first few years of a
    product's
    > code is full of bugs -- just look at IIS 4.0, and the security changes
    > since.

    I have an easy solution for that. If I were a product manager, the test to
    go from beta to GA would require the product be put on the net and allow the
    world to hack it (as in a very public hacking challenge with a substantial $
    reward for hacking it and telling us how you hacked it), when it can stand
    up to that for 30 days without being crashed or rooted then it passed the
    test.

    This would do two things, it would motivate the product team to realize that
    if they don't consider security as a requirement to go GA then the product
    will never see the light of day and it also provides proof to the public
    that it is indeed a secure product and that security is not just a marketing
    phrase..

    > Yes, unfortunately, firewalling is a poor excuse for port shutdown. The
    > fact that out-of-the-box Windows communicates over port 135 is, in my
    > opinion, a design flaw.

    I don't see it that way. I think that as a function to run network backups
    windows has one of the more secure ways to make connections between
    machines. I think MS needs to stop claiming this isn't a feature for the
    internet and realize that there is no difference between the internet and
    the internal network, both require security unless you somehow don't think
    the payroll system requires security..

    One of the things that makes me see this differently is that do security for
    an ISP, the internet IS our internal network for many machines, as the world
    gets more and more connected others are going to realize it's just one big
    network and everything on it needs to be protected not only from the rest of
    the world but from the machine next door.

    Best example I can give you is during the days when the US was being settled
    people used to live in forts for safety, but today people realize that
    security is not a wall but a way of life. The internet is currently at the
    "fort" level of development (firewalled network segments and whatnot) but as
    it becomes more and more universal it gets into homes and everywhere then it
    should become obvious that everything is going to need to be secure and we
    can't depend on build forts for everyone to live in.

    > Disabling the file and print sharing server and client bindings will
    unload
    > 137, 138, and 139 for a given system, but 445 won't shut down without
    > registry modifications that an ordinary users isn't capable of making.
    > Similarly, port 135 and other RPC-only endpoints don't shutdown unless you
    > remove their bindings from the registry.

    I'm here to tell you that you can secure a machine without closing those
    ports. Let me restate that, if you use those ports you can secure them as
    well as you can secure any ports you use on the internet. I agree if they
    aren't being used then shutting them down is the best thing and MS needs to
    make that easy but some of us actually use them on the open net and in that
    case they can be secured as well as anything that's used on the open net.

    Are there bugs that allow compromise over them, sure just like there are
    bugs that allow compromise over any open port. But my point is this isn't
    finger, this is actually something that is useful and I don't want to see it
    go away just because of a few exploits. If you have a webfarm full of NT
    servers how are you going to back them up over the network if you disable
    all windows networking? How are you going to take advantage of windows
    domains single login feature if you don't allow machines to talk to each
    other? It's like telling a unix admin that because of a few exploits SSH
    isn't safe and so it should be disabled. I don't accept that. I want that
    functionality and I want it secured not disabled.

    > Yes, defaults are critical, and you also point out the example of the code
    > base that has the worst security record in MS' history to date: Internet
    > Explorer. I believe that there should be options to disable rarely-needed
    > code like DOM "caching" models. If you read my last post, yes, I use this
    > example a lot. It happens to be the one most insecure, never-needed code
    > example in IE.

    I'm with you here, most of these types of features are the result of "ease
    of use over security" attitude at MS over the years. I believe they have
    recently had a major attitude adjustment though so we'll have to give them
    some time to see just what effect that has on their mindset. They are now
    realizing that security is more important than the ability to include stupid
    sound effects and cutesy animations in an email.

    > Code Red wouldn't have failed -- possibly Nimda, but not Code Red.

    Actually it did, it copied cmd.exe to /scripts/root.exe and it couldn't do
    that if it didn't know the actual directory name on disk (\inetpub\scripts)
    and would fail to infect those machines although it did still crash the
    service.

    > In
    > addition, this kind of thing inhibits the ability to quickly reproduce
    > changes on multiple machines -- essential for patching.

    So what you are saying is that patching my webservers where I have chosen
    random install path names fails? That's news to me. <g> What you have missed
    here is that the path name is available if you have admin access but during
    the exploiting of a machine prior to getting root you don't know the path
    name and it makes things measurably more difficult. It adds a level of
    security by making it tougher for certain exploits where knowing the default
    install path allows you to do things. Any decent hacker will tell you that
    knowing the default install paths helps quite often. I'm suggesting a simple
    change that takes away this advantage.

    Geo.

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Kristian Hermansen: "[Full-Disclosure] Buffer Underflow in popular CD-Writing Sotware"

    Relevant Pages

    • Re: Biometrics
      ... computer to the Internet, it will get attacked. ... They're interesting for learning about attacker behavior and motivations, but they aren't security devices. ... Use Windows 98 Second Edition Machines as a safety internal protocol as ... MVP suggests how the internal safety of 9x is awesome and makes ...
      (microsoft.public.security)
    • Re: SSHD revelaing too much information.
      ... hundreds of machines and really don't see this as a problem. ... The 'green' banner does not attract any ... This goes against my security ... > networks) then make sure you're running a known secure version. ...
      (FreeBSD-Security)
    • Re: Wintards say Vista & XP Security is better than OS X while millions of bots spam the planet
      ... Many of those machines are kept up by people that don't know how to secure their machines. ... Microsoft should have taken things like this in to account and tried to work at thinking about security first but features always sell mass consumer products. ... But some people, including some found in this forum, recommend staying away from Vista citing UAC annoyance as one of the reasons. ...
      (comp.sys.mac.advocacy)
    • Re: Biometrics
      ... keeping them disconnected and physically secure is sage advice. ... great grasp of the security aspect of protecting computers. ... Use Windows 98 Second Edition Machines as a safety internal protocol ... Maintain certain machines as off-line only in locked and secure rooms ...
      (microsoft.public.security)
    • Re: Newsgroup filtering with host server software
      ... I was given permission to hook my personal notebook in to the company network before I had anything to do with our IT department. ... Where I used to work the rule was that you were not allowed to have a mobile switched on in the office (security) so I don't know if they would have worked. ... the internet before it hit my inbox. ... Well, if something could be deemed sufficiently sensitive I would agree that only company machines should be able to access it, after all any other machine could log it even if it was encrypted in transit. ...
      (comp.security.firewalls)