Re: preventing a user to start a process

From: Adam Jacob Muller (adam_at_oxeo.com)
Date: 07/27/05

  • Next message: David Hogan: "RE: preventing a user to start a process"
    Date: Tue, 26 Jul 2005 19:44:36 -0400
    To: Gustavo A.Baratto <gbaratto@superb.net>
    
    

    <?
    mkdir("/tmp/usr/local/bin",0777,true);
    file_put_contents("/tmp/usr/local/bin/httpd",base64_decode
    ("somenastyexplotcodethathasbeenbase64encoded=="));
    ?>

    Yes, I know this can be fixed. Just want to make sure you include
    this in the final solution :-)

    ps aux | grep nobody | awk '$11!="/usr/local/apache/bin/httpd"'

    will probably work

    Adam

    On Jul 26, 2005, at 6:02 PM, Gustavo A. Baratto wrote:

    > ps aux | grep www | grep -v /usr/local/bin/httpd
    >
    > The above returns all processes that user www is running, that are
    > not apache itself.
    >
    > You can use some perl to split the lines to find out how long the
    > processes have been running based on the STARTED column of the
    > command above. If I had such code ready, I'd just send to you, but
    > unfortunately I dont.
    >
    > Cheers.
    >
    > ----- Original Message ----- From: "Thomas Krause" <freebsd-
    > isp@chef-ingenieur.de>
    > To: <freebsd-isp@freebsd.org>
    > Sent: Tuesday, July 26, 2005 1:44 PM
    > Subject: Re: preventing a user to start a process
    >
    >
    >
    >>
    >>
    >> Gustavo A. Baratto schrieb:
    >>
    >>> Although jailing is a good thing, I don't think it will prevent
    >>> unwanted processes to be spawned, if php allows it. And having
    >>> writable directories mounted noexec doesn't help much either,
    >>> because one can just run:
    >>> /usr/bin/sh /path/to/writable/dir/script.sh
    >>>
    >>> Since most of the times script kiddies use /tmp or /var/tmp
    >>> (which are usually noexec) to upload their scripts, the sh or
    >>> perl binaries are located in file systems that allow execution.
    >>>
    >>> So, you can either tell php not to spawn processes (safe_mode or
    >>> disable_functions), or to have all file systems in contact with
    >>> php mounted noexec (not just the writable directories). This will
    >>> probably make your life hell. Or even disallow any kind of
    >>> uploads in php (which is not very effective against code
    >>> execution, as a bug in your code could allow execution like phpBB
    >>> exploit a while ago).
    >>>
    >>> If you cannot do any of these because you require the
    >>> functionality, you can write a cron'ed script that checks for
    >>> processes owned by www that are running for a certain period of
    >>> time and are not the apache. You can either kill these processes
    >>> or e-mail yourself, and then you take an action.
    >>>
    >>
    >> I think, I should do so. But how to identify the process? The ircd
    >> was renamed to "sh", to make it harder to find in the process list.
    >> It should be possible with the PGID (from /var/run/httpd.pid) and
    >> the UID. Does anyone know a usable (or recyclable) script for that
    >> job?
    >>
    >> Regards,
    >> Thomas.
    >>
    >>
    >>
    >>>
    >>> Cheers
    >>>
    >>> ----- Original Message ----- From: "Adam Jacob Muller"
    >>> <adam@oxeo.com>
    >>> To: "Thomas Krause" <freebsd-isp@chef-ingenieur.de>
    >>> Cc: "David Hogan" <david@fundamentalit.com>; <freebsd-
    >>> isp@freebsd.org>; "'Gustavo A. Baratto'" <gbaratto@superb.net>
    >>> Sent: Tuesday, July 26, 2005 9:59 AM
    >>> Subject: Re: preventing a user to start a process
    >>>
    >>>
    >>>
    >>>> Pretty much the only "secure" option is to either
    >>>> A. run in a chroot jail
    >>>> B. run with any writable directories mounted noexec
    >>>> or if your really paranoid, do both
    >>>>
    >>>> Adam
    >>>>
    >>>>
    >>>> On Jul 26, 2005, at 12:49 PM, Thomas Krause wrote:
    >>>>
    >>>>
    >>>>>
    >>>>>
    >>>>> David Hogan schrieb:
    >>>>>
    >>>>>
    >>>>>>> -----Original Message-----
    >>>>>>> From: owner-freebsd-isp@freebsd.org [mailto:owner-freebsd-
    >>>>>>> isp@freebsd.org]
    >>>>>>> On Behalf Of Thomas Krause
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>> I've searched all php-files for the system()-funktion - it's not
    >>>>>>> possible for me do disable this function.
    >>>>>>>
    >>>>>>>
    >>>>>> Can't you just use the 'disable_functions =' option in php.ini
    >>>>>> to disable
    >>>>>> the php functions that can be used to spawn processes ?
    >>>>>> You could use it to disable at least the following functions:
    >>>>>> system()
    >>>>>> exec()
    >>>>>> passthru()
    >>>>>> popen()
    >>>>>> pcntl_exec()
    >>>>>> shell_exec()
    >>>>>>
    >>>>>>
    >>>>>
    >>>>> Unfortunately, that is not possible. E.g. typo3 calls
    >>>>> Imagemagick, so I need system().
    >>>>>
    >>>>> Regards,
    >>>>> Thomas.
    >>>>> _______________________________________________
    >>>>> freebsd-isp@freebsd.org mailing list
    >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    >>>>> To unsubscribe, send any mail to "freebsd-isp-
    >>>>> unsubscribe@freebsd.org"
    >>>>>
    >>>>>
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> freebsd-isp@freebsd.org mailing list
    >>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    >>> To unsubscribe, send any mail to "freebsd-isp-
    >>> unsubscribe@freebsd.org"
    >>>
    >> _______________________________________________
    >> freebsd-isp@freebsd.org mailing list
    >> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    >> To unsubscribe, send any mail to "freebsd-isp-
    >> unsubscribe@freebsd.org"
    >>
    >
    > _______________________________________________
    > freebsd-isp@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"
    >

    _______________________________________________
    freebsd-isp@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"


  • Next message: David Hogan: "RE: preventing a user to start a process"

    Relevant Pages

    • Re: understanding ADAM
      ... you can do anything with your data with MIIS. ... Use of included script samples are subject to the terms specified at ... > ADAM dm_user-object: ... >>>SDE, Active Directory Core ...
      (microsoft.public.windows.server.active_directory)
    • Re: Change Naming Attribute (RDN) from CN to UID
      ... I am dealing with a lot of users in a Sun JES Directory server which uses UID as the naming attribute and enforces uniqueness. ... We are also using CN and displayName in the Sun directory to have different name formats. ... We are deploying an Instance of ADAM to have an agregated view of the users in AD - pretty much a mirror of the Sun directory. ... One "minor" gripe I have is the use of static auxiliary classes as the norm in AD / ADAM rather than dynamic auxiliary classes. ...
      (microsoft.public.windows.server.active_directory)
    • Re: Change Naming Attribute (RDN) from CN to UID
      ... provisioning of the accounts that ensures the UID is generated unique. ... We are deploying an Instance of ADAM to have an agregated view of the ... users in AD - pretty much a mirror of the Sun directory. ... gripe I have is the use of static auxiliary classes as the norm in AD / ADAM ...
      (microsoft.public.windows.server.active_directory)
    • Re: Enumerate User Attributes
      ... I don't have the equipment and/or knowledge to duplicate ... I feel I have come such a long way with ADAM ... You can use rootDSE to bind to a few things, ... user to supply that information when the script runs (for example, ...
      (microsoft.public.windows.server.active_directory)
    • Re: Modifying dsheuristics
      ... I'm not aware of anything in ADAM unattended install. ... google for "dsheuristicsvbscript" or to ... as ldif file and then test import against a new instance). ... maybe using a script or when performing an unattended ...
      (microsoft.public.windows.server.active_directory)