Loading ...
Sorry, an error occurred while loading the content.
 

Re: [gnubies-il] iptables as non-root user

Expand Messages
  • Tzafrir Cohen
    ... apache s authentication is problematic. I would try to use something that is based on ssh for login and authentication. The thing is that you have a number
    Message 1 of 19 , Mar 6, 2002
      On Wed, 6 Mar 2002, Amir Abiri wrote:

      > > > > > On Tue, Mar 05, 2002 at 01:59:27PM +0200, Amir Abiri wrote:
      > > > > > > > > Does anyone know how i can let my apache run iptables ? i have
      > tried to
      > > > > > > > > suid a little shell script for that purpose, but that doesn't
      > work.
      > > > > > > > >Seems like iptables makes it's own double-check that you
      > really are
      > > > > > > > > root.
      > > > > > > > >
      > > > > > > > > Does anyone have any idea ?
      > > > > > > >
      > > > > > > > Maybe a better design would be to write a server that is to be
      > run as root
      > > >> > > > that will run iptables for you, and communicate with this server
      > thru a
      > > > > > > > CGI script using a set of named pipe or a unix-domain socket
      > with
      > > > > > > > permissions that are restrictive enough. We pulled a similar
      > stunt in the
      > > > > > > > IP-Noise project, and it worked beutifully.
      > > > > > >
      > > > > > > Thanks, but thats way too much work for a very simple problem. :)
      > > > > > > Anyway i solved it: "/usr/bin/suidperl".
      > > > > > > Good old perl, where would we be without it ?
      > > > >>
      > > > > > probably in the same place you are with it, with a metric ton of
      > > > > > security holes just waiting to be exploited...
      > > > > >
      > > > > > [ask yourself this: is user input passed *at all* to the suidperl
      > > > > > binary? if it is, my condolences. if not, what's the point?]
      >
      > mulix: There is no "user input", but look at the end of this message.
      >
      > > > > A little less rude remark: make sure this script is well-protected
      >
      > Shlomi: Who was rude to whom again ?
      >
      > > > sometimes, rudeness serves a purpose, such as driving a point home.
      >
      > Or driving ppl away from you. Which is my preferable way of using it...
      >
      > > Well, I'm trying to be as little rude as possible, while being as
      > > informative as I can. I find that explaining yourself clearly is in the
      > > long-term better than trolling people.
      > >
      > > > > (preferably using https), and that it does only what it is allowed to
      > do,
      > > > > and that you check and double check any input for possible exploits.
      >
      > Shlomi: I totaly agree on the https part, i'll look into it.
      >
      > > > amir: do a short search on bugtraq for cgi exploits. compile a list of
      > > > likely offenders (user input not quoted properly, user input not
      > > > sanitized properly) and check how many of those your script is
      > > > vulnerable to. if you want help, send me the url and the script in
      > > > private.
      > > >
      > >
      > > Learning about possible CGI exploits is a good idea. That way one can be a
      > > better programmer.
      >
      > And a better hacker... :)
      >
      > > > > Avoid SUID programs and scripts altogether is not a very wise idea.
      > There
      > > > > are many such utilities on a common Linux installation, but they all
      > > > > follow the guidelines I described. (albeit not successfully all the
      > time,
      > > > > since they may contain bugs)
      > > >
      > > > suid is bad, unlessabsolutely necessary. sudo is better. perhpahs
      > > > amir would like to describe why apachae (running on behalf of some
      > > > user, obviously) needs to execute iptabls at all?
      >
      > It's very simple: I have a firewall blocking all ports but http, smtp, and a
      > couple more like those. ssh is blocked too. The idea is that if i want to
      > log in to my machine from another machine when i'm not home, I can browse to
      > that URL, enter a user name and a password, and if those are correct then
      > another line is entered into the INPUT chain, enabling input only from that
      > specific IP address i'm in. The script also throws the counter iptables
      > command into /bin/at with a time offset of a couple of hours, so after a
      > while the "hole" will be "closed". The ip address is taken from the apache
      > envoirment variable, so it's not "user input", the time is given by the
      > user, but is strictly checked by the PHP script, it can only be a pure
      > number and in a given range.
      >
      > The reason for that suid script is that even if i enable apache to run
      > iptables, it's still not enough. I need ROOT to run those two lines of
      > iptables, and we all agree that letting apache run as root is way worst
      > right ?
      >
      > This script is 5 lines long, and doesn't address the shell at any point, it
      > goes directly to the iptables and at binaries, can only be run by root or
      > apache, and again like i said before: Has no real "user input" in it.

      apache's authentication is problematic. I would try to use something that
      is based on ssh for login and authentication.

      The thing is that you have a number of HTTP sessions for this connection
      because http is a stateless protocol, whereas with ssh you only have one
      session.

      If you want to use a web interface, get a web interface with a proven
      track record, like linuxconf or webmin (you can write a perl script or
      even a bash script that will be a module for linuxconf. You can also make
      a costum menu for linuxconf. I figure this means that SUID may not have
      to be used?)

      Also: what is the IP address exactly? If you use a proxy: won't it be the
      IP of the proxy server?

      Also note that this allows anybody to query the password of your root
      account of your machine from an annonymous web browser. Make sure you
      don't use pam_tally or something, otherwise an aattacker can lock-out your
      root account ;-)

      --
      Tzafrir Cohen /"\
      mailto:tzafrir@... \ / ASCII Ribbon Campaign
      Taub 229, 972-4-829-3942, X Against HTML Mail
      http://www.technion.ac.il/~tzafrir / \
    • Amir Abiri
      ... have ... doesn t ... be ... server ... suidperl ... the ... to ... exploits. ... of ... be a ... idea. ... all ... the ... and a ... to ... browse to ...
      Message 2 of 19 , Mar 6, 2002
        > > > > > > On Tue, Mar 05, 2002 at 01:59:27PM +0200, Amir Abiri wrote:
        > > > > > > > > > Does anyone know how i can let my apache run iptables ? i
        have
        > > tried to
        > > > > > > > > > suid a little shell script for that purpose, but that
        doesn't
        > > work.
        > > > > > > > > >Seems like iptables makes it's own double-check that you
        > > really are
        > > > > > > > > > root.
        > > > > > > > > >
        > > > > > > > > > Does anyone have any idea ?
        > > > > > > > >
        > > > > > > > > Maybe a better design would be to write a server that is to
        be
        > > run as root
        > > > >> > > > that will run iptables for you, and communicate with this
        server
        > > thru a
        > > > > > > > > CGI script using a set of named pipe or a unix-domain socket
        > > with
        > > > > > > > > permissions that are restrictive enough. We pulled a similar
        > > stunt in the
        > > > > > > > > IP-Noise project, and it worked beutifully.
        > > > > > > >
        > > > > > > > Thanks, but thats way too much work for a very simple problem.
        :)
        > > > > > > > Anyway i solved it: "/usr/bin/suidperl".
        > > > > > > > Good old perl, where would we be without it ?
        > > > > >>
        > > > > > > probably in the same place you are with it, with a metric ton of
        > > > > > > security holes just waiting to be exploited...
        > > > > > >
        > > > > > > [ask yourself this: is user input passed *at all* to the
        suidperl
        > > > > > > binary? if it is, my condolences. if not, what's the point?]
        > >
        > > mulix: There is no "user input", but look at the end of this message.
        > >
        > > > > > A little less rude remark: make sure this script is well-protected
        > >
        > > Shlomi: Who was rude to whom again ?
        > >
        > > > > sometimes, rudeness serves a purpose, such as driving a point home.
        > >
        > > Or driving ppl away from you. Which is my preferable way of using it...
        > >
        > > > Well, I'm trying to be as little rude as possible, while being as
        > > > informative as I can. I find that explaining yourself clearly is in
        the
        > > > long-term better than trolling people.
        > > >
        > > > > > (preferably using https), and that it does only what it is allowed
        to
        > > do,
        > > > > > and that you check and double check any input for possible
        exploits.
        > >
        > > Shlomi: I totaly agree on the https part, i'll look into it.
        > >
        > > > > amir: do a short search on bugtraq for cgi exploits. compile a list
        of
        > > > > likely offenders (user input not quoted properly, user input not
        > > > > sanitized properly) and check how many of those your script is
        > > > > vulnerable to. if you want help, send me the url and the script in
        > > > > private.
        > > > >
        > > >
        > > > Learning about possible CGI exploits is a good idea. That way one can
        be a
        > > > better programmer.
        > >
        > > And a better hacker... :)
        > >
        > > > > > Avoid SUID programs and scripts altogether is not a very wise
        idea.
        > > There
        > > > > > are many such utilities on a common Linux installation, but they
        all
        > > > > > follow the guidelines I described. (albeit not successfully all
        the
        > > time,
        > > > > > since they may contain bugs)
        > > > >
        > > > > suid is bad, unlessabsolutely necessary. sudo is better. perhpahs
        > > > > amir would like to describe why apachae (running on behalf of some
        > > > > user, obviously) needs to execute iptabls at all?
        > >
        > > It's very simple: I have a firewall blocking all ports but http, smtp,
        and a
        > > couple more like those. ssh is blocked too. The idea is that if i want
        to
        > > log in to my machine from another machine when i'm not home, I can
        browse to
        > > that URL, enter a user name and a password, and if those are correct
        then
        > > another line is entered into the INPUT chain, enabling input only from
        that
        > > specific IP address i'm in. The script also throws the counter iptables
        > > command into /bin/at with a time offset of a couple of hours, so after a
        > > while the "hole" will be "closed". The ip address is taken from the
        apache
        > > envoirment variable, so it's not "user input", the time is given by the
        > > user, but is strictly checked by the PHP script, it can only be a pure
        > > number and in a given range.
        > >
        > > The reason for that suid script is that even if i enable apache to run
        > > iptables, it's still not enough. I need ROOT to run those two lines of
        > > iptables, and we all agree that letting apache run as root is way worst
        > > right ?
        > >
        > > This script is 5 lines long, and doesn't address the shell at any point,
        it
        > > goes directly to the iptables and at binaries, can only be run by root
        or
        > > apache, and again like i said before: Has no real "user input" in it.
        >
        > apache's authentication is problematic. I would try to use something that
        > is based on ssh for login and authentication.

        Ssh is the the way my box was rooted by last time... :)

        > The thing is that you have a number of HTTP sessions for this connection
        > because http is a stateless protocol, whereas with ssh you only have one
        > session.

        Completly lost you there Tzaffir.

        > If you want to use a web interface, get a web interface with a proven
        > track record, like linuxconf or webmin (you can write a perl script or
        > even a bash script that will be a module for linuxconf. You can also make
        > a costum menu for linuxconf. I figure this means that SUID may not have
        > to be used?)

        I don't want a web interface, i wan the ability to peek in my own smb.conf
        from my friend's house when i'm trying to help him debug his staborn samba
        server.

        > Also: what is the IP address exactly? If you use a proxy: won't it be the
        > IP of the proxy server?

        If i'm behind a proxy then yes that might be a problem, but in most cases i
        can bypass the proxy for a second right ?

        > Also note that this allows anybody to query the password of your root
        > account of your machine from an annonymous web browser. Make sure you
        > don't use pam_tally or something, otherwise an aattacker can lock-out your
        > root account ;-)

        No it doesn't. The PHP script doesn't check the username/password against
        the normal unix user accounts, it's a seperate limited list of (1) users
        with a different password then his unix cuonterpart, and root wasn't
        invited.

        Perhaps you guys are missing the fact that i'm doing this for my home box
        and not any kind of important heavily user loaded work box ? :)
        (Although originally this was an idea of my ex-boss for the servers at the
        office - Can't take the credit...).

        --
        "God is a programmer".
      • mulix
        ... shlomi things i was rude to you, amir. can t say i entirely disagree ;) ... please - cracker. ... sent in PLAIN TEXT. OVER THE INTERNET. [unless you use
        Message 3 of 19 , Mar 6, 2002
          On Wed, Mar 06, 2002 at 08:36:56PM +0200, Amir Abiri wrote:

          > > > > A little less rude remark: make sure this script is well-protected
          >
          > Shlomi: Who was rude to whom again ?

          shlomi things i was rude to you, amir. can't say i entirely disagree ;)

          > > > amir: do a short search on bugtraq for cgi exploits. compile a list of
          > > > likely offenders (user input not quoted properly, user input not
          > > > sanitized properly) and check how many of those your script is
          > > > vulnerable to. if you want help, send me the url and the script in
          > > > private.
          > > >
          > >
          > > Learning about possible CGI exploits is a good idea. That way one can be a
          > > better programmer.
          >
          > And a better hacker... :)

          please - cracker.

          > It's very simple: I have a firewall blocking all ports but http, smtp, and a
          > couple more like those. ssh is blocked too. The idea is that if i want to
          > log in to my machine from another machine when i'm not home, I can browse to
          > that URL, enter a user name and a password, and if those are correct
          > then

          sent in PLAIN TEXT. OVER THE INTERNET.
          [unless you use https, which you dont]

          > another line is entered into the INPUT chain, enabling input only from that
          > specific IP address i'm in. The script also throws the counter
          > iptables

          intput to what services?

          > command into /bin/at with a time offset of a couple of hours, so after a
          > while the "hole" will be "closed". The ip address is taken from the
          > apache

          but until then, it is open, is it not? ever heard of connection
          hijacking? ip spoofing?

          > envoirment variable, so it's not "user input", the time is given by the
          > user, but is strictly checked by the PHP script, it can only be a pure
          > number and in a given range.
          >
          > The reason for that suid script is that even if i enable apache to run
          > iptables, it's still not enough. I need ROOT to run those two lines of
          > iptables, and we all agree that letting apache run as root is way worst
          > right ?

          definitely.

          > This script is 5 lines long, and doesn't address the shell at any point, it
          > goes directly to the iptables and at binaries, can only be run by root or
          > apache, and again like i said before: Has no real "user input" in
          > it.

          the script doesnt appear to be broken, but the design is.

          it's all a matter of levels of paranoya. for what you are trying to
          protect, it might be enough. if it was for access to an organization's
          network, and i was doing a security audit on them, i would scream
          bloody murder.
          --
          The ill-formed Orange
          Fails to satisfy the eye: http://vipe.technion.ac.il/~mulix/
          Segmentation fault. http://syscalltrack.sf.net/
        • Tzafrir Cohen
          ... It s input is the source IP, which is given as an environment variable (?) ... Because it was not properly upgraded following the vendor s instructions.
          Message 4 of 19 , Mar 6, 2002
            On Wed, 6 Mar 2002, Amir Abiri wrote:

            > > Amir Abiri wrote:

            > > > It's very simple: I have a firewall blocking all ports but http, smtp, and a
            > > > couple more like those. ssh is blocked too. The idea is that if i want to
            > > > log in to my machine from another machine when i'm not home, I can browse to
            > > > that URL, enter a user name and a password, and if those are correct then
            > > > another line is entered into the INPUT chain, enabling input only from that
            > > > specific IP address i'm in. The script also throws the counter iptables
            > > > command into /bin/at with a time offset of a couple of hours, so after a
            > > > while the "hole" will be "closed". The ip address is taken from the apache
            > > > envoirment variable, so it's not "user input", the time is given by the
            > > > user, but is strictly checked by the PHP script, it can only be a pure
            > > >number and in a given range.
            > > >
            > > > The reason for that suid script is that even if i enable apache to run
            > > > iptables, it's still not enough. I need ROOT to run those two lines of
            > > > iptables, and we all agree that letting apache run as root is way worst
            > > > right ?
            > > >
            > > > This script is 5 lines long, and doesn't address the shell at any point, it
            > > > goes directly to the iptables and at binaries, can only be run by root or
            > > > apache, and again like i said before: Has no real "user input" in it.

            It's input is the source IP, which is given as an environment variable (?)

            > >
            > > apache's authentication is problematic. I would try to use something that
            > > is based on ssh for login and authentication.
            >
            > Ssh is the the way my box was rooted by last time... :)

            Because it was not properly upgraded following the vendor's instructions.

            BTW: have you upgraded PHP?

            >
            > > The thing is that you have a number of HTTP sessions for this connection
            > > because http is a stateless protocol, whereas with ssh you only have one
            > > session.
            >
            > Completly lost you there Tzaffir.

            Thinking about this again, my assumption was not entirly correct. There is
            only one http session (server gets username+password from user, and
            executes script).

            >
            > > If you want to use a web interface, get a web interface with a proven
            > > track record, like linuxconf or webmin (you can write a perl script or
            > > even a bash script that will be a module for linuxconf. You can also make
            > > a costum menu for linuxconf. I figure this means that SUID may not have
            > > to be used?)
            >
            > I don't want a web interface, i wan the ability to peek in my own smb.conf
            > from my friend's house when i'm trying to help him debug his staborn samba
            > server.

            Amir: please read carefuly what I wrote: writing a SUID program has many
            gotchas. The idea was to use an existing one (e.g: linuxconf) to avoid
            introducing your own bugs

            >
            > Perhaps you guys are missing the fact that i'm doing this for my home box
            > and not any kind of important heavily user loaded work box ? :)

            Many times I see the installation instructions of various PHP scripts,
            that include stuff like 'chmod -R 777' , and that 'this is safe, becase
            there are if there are no local shell users'. Well, this is plain wrong.
            Sooner or later someone will manage to get a shell there. Giving that one
            a way to elavate its priviliges to root (or to do something almost
            as bad: free access to iptables) is not what you need.

            Since your computer shares the internet with my computer and can be used
            to attack my computer in case it will be hijacked, I don't want it or any
            other computer to be broken into (I can still hope...)

            --
            Tzafrir Cohen /"\
            mailto:tzafrir@... \ / ASCII Ribbon Campaign
            Taub 229, 972-4-829-3942, X Against HTML Mail
            http://www.technion.ac.il/~tzafrir / \
          • Amir Abiri
            From: mulix ... Right... [Turns backward, looking for something...] ... Yes. I m the one doing the holes, so most of the time i kick
            Message 5 of 19 , Mar 7, 2002
              From: "mulix" <mulix@...>

              > On Wed, Mar 06, 2002 at 08:36:56PM +0200, Amir Abiri wrote:
              > > > > > A little less rude remark: make sure this script is well-protected
              > >
              > > Shlomi: Who was rude to whom again ?
              >
              > shlomi things i was rude to you, amir. can't say i entirely disagree ;)

              Right... [Turns backward, looking for something...]

              > > command into /bin/at with a time offset of a couple of hours, so after a
              > > while the "hole" will be "closed". The ip address is taken from the
              > > apache
              >
              > but until then, it is open, is it not? ever heard of connection
              > hijacking? ip spoofing?

              Yes. I'm the one doing the holes, so most of the time i kick myself out when
              i finish. ( So much *fun* playing *iptables -D INPUT -s $Your_self -j
              ACCEPT* in the *middle* !)
              The at part is just for making sure the "hole" doesn't stay open forever.

              > it's all a matter of levels of paranoya. for what you are trying to
              > protect, it might be enough. if it was for access to an organization's
              > network, and i was doing a security audit on them, i would scream
              > bloody murder.

              (Might be ?...)
              Anyway i wouldn't dream to do this for a serious organization. If that was
              the case i would obviously be way more paranoid. Or take the money and
              escape to colombia, use it to buy drugs, sell them, and live happily ever
              after.

              --
              "God is a programmer".
            • Tzafrir Cohen
              ... Why do you do this in the input chain? messing the default chains is probably error-prone direct all the relevant ssh traffic (ssh is enough. And you can
              Message 6 of 19 , Mar 7, 2002
                On Thu, 7 Mar 2002, Amir Abiri wrote:

                > From: "mulix" <mulix@...>
                >
                > > On Wed, Mar 06, 2002 at 08:36:56PM +0200, Amir Abiri wrote:

                > > > command into /bin/at with a time offset of a couple of hours, so after a
                > > > while the "hole" will be "closed". The ip address is taken from the
                > > > apache
                > >
                > > but until then, it is open, is it not? ever heard of connection
                > > hijacking? ip spoofing?
                >
                > Yes. I'm the one doing the holes, so most of the time i kick myself out when
                > i finish. ( So much *fun* playing *iptables -D INPUT -s $Your_self -j
                > ACCEPT* in the *middle* !)

                Why do you do this in the input chain?

                messing the default chains is probably error-prone

                direct all the relevant ssh traffic (ssh is enough. And you can tunnel
                anything on top of it...) to a seperate chain, and the script will only
                touch this chain. This means that whatever happens, this script will only
                mess up your ssh traffic, and your www server eill stay accessible.

                BTW: if the box is connected in a permanent connection, exposing an sshd
                is not a bad idea, IMHO. (provided that you follow vendor security
                updates, that is). I think you'll find it to be a useful "base of
                operations".

                --
                Tzafrir Cohen /"\
                mailto:tzafrir@... \ / ASCII Ribbon Campaign
                Taub 229, 972-4-829-3942, X Against HTML Mail
                http://www.technion.ac.il/~tzafrir / \
              Your message has been successfully submitted and would be delivered to recipients shortly.