Likes Likes:  0
Resultaten 1 tot 12 van de 12
Geen
  1. #1
    Radko Keves
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Unprivilegued settings for FreeBSD kernel variables

    CATEGORY:
    kern

    INTRODUCTION:
    i have found security threat in basic security facility in BSD systems
    that allows to lower sysctl variable

    in this case to bypass security settings, root privilegues are needed


    DESCRIPTION:
    sysctl(8)
    ....
    The sysctl utility retrieves kernel state and allows processes with
    appropriate privilege to set kernel state. The state to be retrieved or
    set is described using a ``Management Information Base'' (``MIB'') style
    name, described as a dotted set of components.
    ....
    kern.securelevel integer raise only
    ....

    security(7)
    ....
    Once you have set the securelevel to 1, write access to raw devices will
    be denied and special chflags flags, such as `schg', will be enforced.
    ....

    sysctl(3)
    ....
    KERN_SECURELVL
    The system security level. This level may be raised by processes
    with appropriate privilege. It may not be lowered.
    ....


    PROBLEM:
    raise only kernel variables aren't really raise only, here is the
    way how we can avoid security settings


    EXAMPLE:
    kernel module can gives you a new sysctl (for example kern.securelevel2):
    kern.securelevel2
    with which you can lower/raiser sysctl.securelevel variable
    (source code attached)

    $ kldstat
    Id Refs Address Size Name
    1 7 0xc0400000 4378e4 kernel
    ...
    $
    $ kldload ./securelevel2.ko
    $ kldstat
    Id Refs Address Size Name
    1 8 0xc0400000 4378e4 kernel
    ...
    8 1 0xc4e96000 2000 securelevel2.ko

    $sudo sysctl kern.securelevel
    kern.securelevel: -1
    $sudo sysctl kern.securelevel=3
    kern.securelevel: -1 -> 3
    $ sudo sysctl kern.securelevel
    kern.securelevel: 3
    $ sudo sysctl kern.securelevel=-1
    kern.securelevel: 3
    sysctl: kern.securelevel: Operation not permitted
    $ sudo sysctl kern.securelevel2=-1
    kern.securelevel2: 3 -> -1
    $ sudo sysctl kern.securelevel
    kern.securelevel: -1
    $ uname -a
    FreeBSD mk 5.2.1-RELEASE-p5 FreeBSD 5.2.1-RELEASE-p5 #8: Wed Jun 2 11:23:59 CEST 2004 rado@mk:/xx/angel i386


    CODE:
    [...]
    static int sysctl_securelevel2(SYSCTL_HANDLER_ARGS) {
    int error;
    error = sysctl_handle_long(oidp,&(securelevel), 0, req);
    return (error);
    }
    SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_securelevel2, "I", ".");
    [...]


    WORKAROUND:
    not known


    SEE ALSO:
    other "raise only" :-) sysctl variables (uptime....), write access to raw devices...


    STATUE:
    still better than others


    AFFECTED DISTRIBUTIONS:
    FreeBSD 5.x i386
    FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)


    LAST WORDS:
    i think i'm paranoid, but i want some measures to be taken
    FreeBSD team was informed


    Best regards,
    --
    Radko <rado@daemon.sk>

  2. #2
    Dag-Erling Smørgrav
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    Radko Keves <rado@unitra.sk> writes:
    > i have found security threat in basic security facility in BSD systems
    > that allows to lower sysctl variable


    I've already told you that there is no such threat, since the attack
    you describe can only be initiated by someone who already has
    unrestricted access. Please stop wasting everybody's time.

    DES
    --=20
    Dag-Erling Sm=F8rgrav - des@des.no

  3. #3
    Manuel Bouyer
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
    > [...]
    >
    > AFFECTED DISTRIBUTIONS:
    > FreeBSD 5.x i386
    > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)


    NetBSD is not, a LKM can't be loaded if securelevel is > 0.

    --
    Manuel Bouyer <bouyer@antioche.eu.org>
    NetBSD: 24 ans d'experience feront toujours la difference
    --

  4. #4
    Eygene A. Ryabinkin
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    On Tue, Jun 15, 2004 at 09:01:13PM +0200, Dag-Erling Sm?rgrav wrote:
    > I've already told you that there is no such threat, since the attack
    > you describe can only be initiated by someone who already has
    > unrestricted access. Please stop wasting everybody's time.

    You are wrong. Unrestricted access means _really unrestricted_ and
    kernel securelevel restricts access to certain places even to root.
    IMHO, it's dagerous bug, because some administrators can think "...hmm,
    I've enabled the hardest securelevel and even if a hacker would break
    into my host with r00t privileges he will be restricted in certain ways.
    The only thing he can do is to change /etc/rc.conf (for example) and
    _reboot_ my host. But I will notice the reboot." So, for certain
    people the following formulae may hold:
    Hardest securelevel + no reboots = good security.

    But this bug changes things. One can lower securelevel, do some nasty things
    and raise it again _without reboots_. So, as I've already noted, you are wrong.
    The bug _gives_ you almost unrestricted access.
    rea

  5. #5
    Jason V. Miller
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    Please have a look at my post in response to the original message, as there
    is some misunderstanding here.

    If an attacker compromises a machine running at security level 3, then they
    cannot lower the securelevel sysctl. The "technique" used in the original
    post involved loading an arbitrary kernel module while the system was still
    running at security level -1, which basically introduced a backdoor into
    the kernel that would allow an attacker to lower it afterwards.

    As DES explains, the attacker would require unrestricted access (at
    security level < 1) in order to implement this "attack". It's not a
    vulnerability.

    J.

    On Thu, Jun 17, 2004 at 06:33:49PM +0400, Eygene A. Ryabinkin wrote:
    > On Tue, Jun 15, 2004 at 09:01:13PM +0200, Dag-Erling Sm?rgrav wrote:
    > > I've already told you that there is no such threat, since the attack
    > > you describe can only be initiated by someone who already has
    > > unrestricted access. Please stop wasting everybody's time.

    > You are wrong. Unrestricted access means _really unrestricted_ and
    > kernel securelevel restricts access to certain places even to root.
    > IMHO, it's dagerous bug, because some administrators can think "...hmm,
    > I've enabled the hardest securelevel and even if a hacker would break
    > into my host with r00t privileges he will be restricted in certain ways.
    > The only thing he can do is to change /etc/rc.conf (for example) and
    > _reboot_ my host. But I will notice the reboot." So, for certain
    > people the following formulae may hold:
    > Hardest securelevel + no reboots = good security.
    >
    > But this bug changes things. One can lower securelevel, do some nasty things
    > and raise it again _without reboots_. So, as I've already noted, you are wrong.
    > The bug _gives_ you almost unrestricted access.
    > rea


    --
    Jason V. Miller, Threat Analyst
    Symantec, Inc. - www.symantec.com
    E-Mail: jmiller@securityfocus.com

  6. #6
    Christian Ullrich
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    * Eygene A. Ryabinkin wrote on Thursday, 2004-06-17:

    > On Tue, Jun 15, 2004 at 09:01:13PM +0200, Dag-Erling Sm=C3=B8rgrav wrot=

    e:

    > > I've already told you that there is no such threat, since the attack
    > > you describe can only be initiated by someone who already has
    > > unrestricted access. Please stop wasting everybody's time.


    > You are wrong. Unrestricted access means _really unrestricted_ and
    > kernel securelevel restricts access to certain places even to root.


    Quite correct.

    > IMHO, it's dagerous bug, because some administrators can think "...hmm,
    > I've enabled the hardest securelevel and even if a hacker would break
    > into my host with r00t privileges he will be restricted in certain ways=

    ..

    Correct as well.

    > But this bug changes things. One can lower securelevel, do some nasty=20
    > things and raise it again _without reboots_. So, as I've already=20
    > noted, you are wrong.


    No. You CAN'T load or unload kernel modules if securelevel is > 0.

    To make your attack work, the attacker would have to have access to
    the system before it ever went to securelevel 1, 2 or 3, in order to
    load the very kernel module your attack requires. Since that almost
    certainly means that he had to be in the same room with the system,
    I think "can only be initiated by someone who already has unrestricted
    access" is completely correct.

    --=20
    Christian Ullrich

    "There's nothing we can't face -- except for Bun-bun..."

  7. #7
    Valdis.Kletnieks@vt.edu
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    --==_Exmh_1855029643P
    Content-Type: text/plain; charset=us-ascii

    On Thu, 17 Jun 2004 13:28:59 +0200, Manuel Bouyer said:
    > On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
    > > [...]
    > >
    > > AFFECTED DISTRIBUTIONS:
    > > FreeBSD 5.x i386
    > > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)

    >
    > NetBSD is not, a LKM can't be loaded if securelevel is > 0.


    Note *very* carefully the fact that the statement "you can't load a LKM" is not
    totally identical to "you can't cause an LKM to be in the kernel".

    Hunt down the Phrack article on loading an LKM into a Linux kernel *that
    doesn't even have module support*, and ask yourself if you're quite as sure
    that there is *zero* vulnerability there....


    --==_Exmh_1855029643P
    Content-Type: application/pgp-signature

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFA015DcC3lWbTT17ARAubyAKD1fTG4DYYgh9hMdjpn4W wmPgPX8wCfXyMZ
    jPTutJazqXAAsyXGu8GleLc=
    =p/5Z
    -----END PGP SIGNATURE-----

    --==_Exmh_1855029643P--

  8. #8
    Ivaylo Kostadinov
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    Dag-Erling Smørgrav wrote:
    > I've already told you that there is no such threat, since the attack
    > you describe can only be initiated by someone who already has
    > unrestricted access. Please stop wasting everybody's time.



    If the vulnerability described exists then there is such a threat.

    The sole purpose of the FreeBSD secure levels is to prevent even someone
    with unrestricted access from performing certain operations unless
    working on the console and the system is in "maintenance" mode.

    Imagine a bootable-CD-only FreeBSD system acting as router/firewall in
    securelevel 3. Even if somehow a hacker gets remote access to the system
    she/he will not be able to change the firewall setup.
    If however the hacker is able to reduce the secure level the she/he can
    reconfigure the firewall and thus disrupt the only function the system
    is meant to perform.


    This said if we look at the described "... security threat in basic
    security facility..." :

    >
    > EXAMPLE:
    > kernel module can gives you a new sysctl (for example kern.securelevel2):
    > kern.securelevel2
    > with which you can lower/raiser sysctl.securelevel variable
    > (source code attached)
    >
    > $ kldstat
    > Id Refs Address Size Name
    > 1 7 0xc0400000 4378e4 kernel
    > ...
    > $
    > $ kldload ./securelevel2.ko
    > $ kldstat
    > Id Refs Address Size Name
    > 1 8 0xc0400000 4378e4 kernel
    > ...
    > 8 1 0xc4e96000 2000 securelevel2.ko



    Why would you want to load the above-mentioned module? I mean except for
    the purpose of exposing the securelevel2 variable.

    This command only:

    > sudo sysctl kern.securelevel=3


    will safely put the system in the corresponding securelevel


    > SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW,

    0, 0, sysctl_securelevel2, "I", ".");
    > [...]
    >


    I have not checked where this code is from but it seems to me that the
    CTLFLAG_SECURE or similar flags are missing there.
    Does this not indicate that the sysctl variable is intended to be
    modifiable at any securelevel?


    In conclusion, the described scenario would reduce the securelevel but
    it will have to be engineered and greatly helped by the rightful admin
    of the system.
    And I must say I have definitely seen easier ways to Trojan-horse your
    own host.


    Best wishes,

    ivaylo kostadinov


  9. #9
    Henning Brauer
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    * Manuel Bouyer <bouyer@antioche.eu.org> [2004-06-18 12:46]:
    > On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
    > > [...]
    > >
    > > AFFECTED DISTRIBUTIONS:
    > > FreeBSD 5.x i386
    > > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)

    >
    > NetBSD is not, a LKM can't be loaded if securelevel is > 0.


    Same applies for OpenBSD.

    --
    Henning Brauer, BS Web Services, http://bsws.de
    hb@bsws.de - henning@openbsd.org
    Unix is very simple, but it takes a genius to understand the simplicity.
    (Dennis Ritchie)

  10. #10
    Jason V. Miller
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    This is not a vulnerability. Perhaps you should discuss "problems" like this
    a little more before you post your findings to 5 different security mailing
    lists, as it appears that you've done nothing more than confuse people
    about an issue that really doesn't exist.

    Comments inline.

    On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
    > CATEGORY:
    > kern
    >
    > INTRODUCTION:
    > i have found security threat in basic security facility in BSD systems
    > that allows to lower sysctl variable
    >
    > in this case to bypass security settings, root privilegues are needed


    [snip]

    > PROBLEM:
    > raise only kernel variables aren't really raise only, here is the
    > way how we can avoid security settings


    You're not exploiting a bug, you're implementing a new interface into the
    kernel that doesn't enforce the established policies regarding the kernel
    security levels.

    > EXAMPLE:
    > kernel module can gives you a new sysctl (for example kern.securelevel2):
    > kern.securelevel2
    > with which you can lower/raiser sysctl.securelevel variable
    > (source code attached)
    >
    > $ kldstat
    > Id Refs Address Size Name
    > 1 7 0xc0400000 4378e4 kernel
    > ...
    > $
    > $ kldload ./securelevel2.ko


    The point is that you're loading a kernel module that introduces a policy
    error in handling the secure level sysctl. This isn't a vulnerability in
    FreeBSD.

    At this point, you've violated the kernel and can no longer trust secure
    level 3. If the system was at secure level 3 (or > 0) in the first place, you
    wouldn't have been able to load your kernel module that violates the sysctl
    lower policy.

    > $ kldstat
    > Id Refs Address Size Name
    > 1 8 0xc0400000 4378e4 kernel
    > ...
    > 8 1 0xc4e96000 2000 securelevel2.ko
    >
    > $sudo sysctl kern.securelevel
    > kern.securelevel: -1
    > $sudo sysctl kern.securelevel=3
    > kern.securelevel: -1 -> 3
    > $ sudo sysctl kern.securelevel
    > kern.securelevel: 3
    > $ sudo sysctl kern.securelevel=-1
    > kern.securelevel: 3
    > sysctl: kern.securelevel: Operation not permitted
    > $ sudo sysctl kern.securelevel2=-1
    > kern.securelevel2: 3 -> -1


    And now, you're lowering the secure level through your own interface, which
    really has nothing to do with the base FreeBSD kernel at all. There is no
    way to prevent this behavior. It's not a vulnerability. I don't know of an
    easier way to explain this to you.

    > $ sudo sysctl kern.securelevel
    > kern.securelevel: -1
    > $ uname -a
    > FreeBSD mk 5.2.1-RELEASE-p5 FreeBSD 5.2.1-RELEASE-p5 #8: Wed Jun 2 11:23:59 CEST 2004 rado@mk:/xx/angel i386
    >
    >
    > CODE:
    > [...]
    > static int sysctl_securelevel2(SYSCTL_HANDLER_ARGS) {
    > int error;
    > error = sysctl_handle_long(oidp,&(securelevel), 0, req);
    > return (error);
    > }
    > SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_securelevel2, "I", ".");
    > [...]
    >
    >
    > WORKAROUND:
    > not known
    >
    >
    > SEE ALSO:
    > other "raise only" :-) sysctl variables (uptime....), write access to raw devices...
    >
    >
    > STATUE:
    > still better than others
    >
    >
    > AFFECTED DISTRIBUTIONS:
    > FreeBSD 5.x i386
    > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)
    >
    >
    > LAST WORDS:
    > i think i'm paranoid, but i want some measures to be taken
    > FreeBSD team was informed
    >
    >
    > Best regards,
    > --
    > Radko <rado@daemon.sk>


    --
    Jason V. Miller, Threat Analyst
    Symantec, Inc. - www.symantec.com
    E-Mail: jmiller@securityfocus.com

  11. #11
    blexim
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    >> I've already told you that there is no such threat, since the attack
    >> you describe can only be initiated by someone who already has
    >> unrestricted access. Please stop wasting everybody's time.

    > You are wrong. Unrestricted access means _really unrestricted_ and
    >kernel securelevel restricts access to certain places even to root.
    >IMHO, it's dagerous bug, because some administrators can think "...hmm,


    >I've enabled the hardest securelevel and even if a hacker would break
    >into my host with r00t privileges he will be restricted in certain ways.
    >The only thing he can do is to change /etc/rc.conf (for example) and
    >_reboot_ my host. But I will notice the reboot." So, for certain
    >people the following formulae may hold:
    > Hardest securelevel + no reboots = good security.
    >
    > But this bug changes things. One can lower securelevel, do some nasty

    things
    >and raise it again _without reboots_. So, as I've already noted, you

    are wrong.
    >The bug _gives_ you almost unrestricted access.


    You can't load the LKM unless securelevel <= 0. Therefore, if securelevel
    > 0 (the default securelevel for multi-user operation is 1) you can't

    load your evil LKM & thus can't lower the securelevel. Essentially this
    means that if the securelevel is 0 or lower, you can lower it even further,
    but if this is the case there are no protections effected by securelevel
    anyway. In other words, there is absolutely no threat presented by the
    attack you describe.

    blexim
    -----BEGIN PGP SIGNATURE-----
    Note: This signature can be verified at https://www.hushtools.com/verify
    Version: Hush 2.4

    wkYEARECAAYFAkDTKTMACgkQsE7ilXLZoGa3vwCdEM0+r9e9OM BvXs8HXIsVyIsCzDgA
    n2CffOjRHyMfT3WdLCY9opAV9qdK
    =uDmH
    -----END PGP SIGNATURE-----




    Concerned about your privacy? Follow this link to get
    secure FREE email: http://www.hushmail.com/?l=2

    Free, ultra-private instant messaging with Hush Messenger
    http://www.hushmail.com/services.php...essenger&l=434

    Promote security and make money with the Hushmail Affiliate Program:
    http://www.hushmail.com/about.php?su...ffiliate&l=427

  12. #12
    Wietse Venema
    Unprivilegued settings for FreeBSD kernel variables
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Unprivilegued settings for FreeBSD kernel variables

    Valdis.Kletnieks@vt.edu:
    -- Start of PGP signed section.
    > On Thu, 17 Jun 2004 13:28:59 +0200, Manuel Bouyer said:
    > > On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
    > > > [...]
    > > >
    > > > AFFECTED DISTRIBUTIONS:
    > > > FreeBSD 5.x i386
    > > > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)

    > >
    > > NetBSD is not, a LKM can't be loaded if securelevel is > 0.

    >
    > Note *very* carefully the fact that the statement "you can't load a LKM" is not
    > totally identical to "you can't cause an LKM to be in the kernel".
    >
    > Hunt down the Phrack article on loading an LKM into a Linux kernel *that
    > doesn't even have module support*, and ask yourself if you're quite as sure
    > that there is *zero* vulnerability there....


    FYI, with BSD securelevel > 0, you can't poke a module into the
    kernel via /dev/*mem, so this Linux loading method won't work.

    Likewise, write access to mounted devices is forbidden. Without
    such restrictions, securelevels would be pretty much meaningless.

    For more details, please see "man securelevel" or equivalent.

    Wietse

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics