Re: [Full-Disclosure] Frontpage Extensions Remote Command Execution

From: Damian Gerow (
Date: 11/12/03

  • Next message: Gadi Evron: "Re: [Full-Disclosure] Microsoft prepares security assault on Linux"
    Date: Wed, 12 Nov 2003 17:53:36 -0500

    Thus spake Paul Schmehl ( [12/11/03 17:21]:
    > You're serious? I mean *really* serious? Or is this a test?

    Really, *really* serious.

    > How do you explain this, for example?

    What do I need to explain?

    There's nothing in that document that says, 'After installing apache, unless
    you do this simple task, you are open to a vulnerability.'

    At its worst, it says, 'Because Apache runs as a specific user, and thus all
    configured sites run as that user, these users can potentially attack each

    (In fact, there has been a vulnerability released in the past year (six
    months?) that has let people do exactly that. So that is the only real
    point of concern.)

    However, let's look at the installation.

    I use FreeBSD. So I install the www/apache13 (or www/apache13-modssl) port.
    It installs, doesn't enable SSI, has suEXEC configured in it by default,
    runs as a non-root user, and has pretty sane restrictions on what it can and
    cannot serve. As well, www/apache13 already has 'AllowOverride None' on /.

    So I don't have to worry about SSI stuff, but CGI stuff is still a concern.
    But I already have suEXEC enabled, so I just need to attach the users (yes,
    this is a bit of a concern, I agree), and I've already attained 90% of the
    'To run a really tight ship, do ...' the document specifies.

    Let's take this a step further.

    I want webmail. So I install the www/horde port. And look at that -- it
    *also* installs with sane restrictions, so that people can't view my
    documents or configuration files.

    So I really do fail to see what I need to explain. I still stand by what I
    said, that a decent OS shouldn't need the admin to go in afterwards and
    modify filesystem permissions in order to guarantee a base line of

    The biggest problem I see here is that there is no example for suEXEC in the
    configuration file. And Apache could perhaps enable suEXEC by default for
    /~jschmoe URLs (or does it -- I don't know).

    The other big concern is the installation of www/mod_php4, www/mod_perl, and
    the like. Not under suEXEC, you are pretty much open to do what you want as
    the web server. That includes potentially killing any of the children httpd

    Under suEXEC, you are open to do what you want as the user. That does *not*
    include killing any httpd processes.

    However, this is considerably more complicated than a, 'this file should not
    have been installed with such loose permissions' problem. This is a
    continuing, ongoing configuration problem, not a one-time fixup due to a
    problem in the install.

    So to get this up and running with a base line of security, I did *not* have
    to once go in and change the permissions on any of the files that the port

    It's entirely possible that I have missed something glaringly obvious (that
    happens when you focus on multiple things at once), so please, point it out
    to me if I have.

      - Damian

    * = In reviewing my comment, I should also state this: While this came as a
    direct result of a Microsoft-ism, this also applies to any other platform.
    OS X has had its own filesystem permission problems (OS X Server, I'm not
    sure about), and I'm sure that somewhere in the history of Open Source there
    have been security issues with default permissions. Not to mention Solaris,
    AIX, Irix, AUX...

    Full-Disclosure - We believe in it.

  • Next message: Gadi Evron: "Re: [Full-Disclosure] Microsoft prepares security assault on Linux"