[security] Local Root Explot for Kernel 2.6.21! - Slackware

This is a discussion on [security] Local Root Explot for Kernel 2.6.21! - Slackware ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2008-02-13, Robby Workman wrote: >> I don't talk about contributions to Slackware itself. The "alternative >> source" of security packages would have to be located as separate >> project. Not anyone would need ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: [security] Local Root Explot for Kernel 2.6.21!

  1. Re: [security] Local Root Explot for Kernel 2.6.21!

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

    On 2008-02-13, Robby Workman wrote:
    >> I don't talk about contributions to Slackware itself. The "alternative
    >> source" of security packages would have to be located as separate
    >> project. Not anyone would need those updates. For many people the
    >> official updates will do just right. The "alternative updates project"
    >> would be for those who want a bit more security by patching *any* hole
    >> that gets published. Maybe with an small auto updater anyone may use to
    >> auto-fetch the updates.


    As some one who was involved in the SlackSec project that you seem to
    have thought so highly of (thank you for your recommendation, btw), I
    think I'm in a good position to say that *nobody* in his right mind
    wants this job. It is a thankless, difficult, time-consuming, and
    boring task that is made all the more difficult by people who seem to
    think that all "security vulnerabilities" are created equal, when in
    fact they simply are not. More on this later.

    > IOW, instead of an occasional *known* hole (usually of minimal impact or
    > something that is easily worked around or mitigated) that takes a week or
    > so for official updates to post (along with the assurance that the update
    > has actually been tested), you seem to be proposing a third party package
    > made by someone with no affiliation with Slackware at all. For those who
    > haven't made the connection, that's a transition from *known* issues to
    > *unknown* issues.


    Well in that case it mostly boils down to trust. How do I know that I
    can trust these people? In the open source community, it's largely
    easy to develop at least a modicum of trust simply by being transparent.
    For instance, with SlackSec, not only were packages made available, but
    source code, gpg signatures, and build scripts were also published.
    Even if some one didn't feel like they could trust us (and being
    completely unofficial, we operated with that assumption) that person
    could self-audit the build scripts, obtain the source code from some
    other location, and easily create their own packages.

    > So many of the "security" bugs that arise are of questionable impact.


    Amen.

    > That's not to say that they're not issues - they clearly are - but when
    > a potential vulnerability does not published exploit code, and/or the
    > maintainers of the software say that the potential exploit condition is
    > controlled in other parts of the code (before the input/whatever even
    > reaches the "vulnerable" part), and/or the "fix" breaks everything that
    > links against the "vulnerable" library (which means that you have to
    > choose from "security" or "usability," then hard decisions have to be
    > made. It's easy for you and various others to whine on public forums
    > about security issues not being addressed in a timely manner, but until
    > you've had to make some of those "hard decisions" and then live with the
    > consequences they cause on your entire user community, then I dare say
    > you shouldn't be quite so vocal.


    To take this one step further, I'm going to paraphrase Bruce Schneider
    here. There is always a trade-off when dealing with security, and that
    trade-off needs to be analyzed for the different points of view of
    everyone involved. Let's say I publish a Linux distro based on
    Slackware and I call it Alanux. A vulnerability is "found" in the
    version of samba shipped with Alanux that allows a local attacker to
    gain root privilages if an exotic configuration option is present in
    smb.conf. Alanux doesn't turn this option on by default, and unless
    it's present, the bug cannot be exploited.

    Now, I have to decide if this is worth patching for me. The samba
    team has decided that they will no longer support the version of samba
    shipped in Alanux and won't even generate patches for it. I now have
    several choices.

    A) Don't patch it. Anyone running samba probably doesn't have any
    local users on the system anyway, especially if they're using
    config_exotic.
    B) Create and support my own patch to samba. This is perhaps the least
    desirable option as it means I will essentially have to maintain my own
    fork of the samba code for however long I intend to support this
    version of Alanux.
    C) Upgrade to the latest supported version of samba, thoroughly test it
    to the best of my abilities, and hope it doesn't break anyone's system.

    Now if you are the user and an updated package is released, your
    choices are much much simpler.

    A) Ignore it. You're probably not using config_exotic anyhow, and if
    you are, it is only a local exploit. Unless your samba server is
    running other services with known remote user vulnerabilities, or you
    expose those services to the Internet, the odds of anyone exploiting
    this vulnerability are infintesmal.
    B) Upgrade to the new package and hope it doesn't break anything. Even
    if it does, down-grading to the previous package is straight-forward
    and easy.

    In other words, as a user, you've got basically nothing to loose, but
    as the publisher, you have to make hard decisions not only for
    yourself, but for all users.

    So don't be in a hurry to criticize Pat or any other distro maintainer
    regaurding timely fixes for what ammounts to nothing more than
    low-impact local exploits.

    - --
    It is better to hear the rebuke of the wise,
    Than for a man to hear the song of fools.
    Ecclesiastes 7:5
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHsykZrZS6hX/gvjoRAkDOAJwMEcije9GJvV8oCP8jXXVClLL/mQCg0Kps
    eTEmrrYgCAe8SDrw5JPguvI=
    =7W1V
    -----END PGP SIGNATURE-----

  2. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-13, Robby Workman wrote:
    > On 2008-02-13, Res wrote:
    >> On Tue, 12 Feb 2008, Keith Keller wrote:
    >>
    >>>> Real servers do not allow telnet, do not allow anyone but sys admins
    >>>> access to ssh,
    >>>
    >>> This is of course completely untrue. How would one work remotely
    >>> otherwise? IPSec is one option, but how many of your users are going to
    >>> go through that much trouble?

    >>
    >>
    >> Bull****, if you dont restrict access to it, you deserve everything you
    >> get.
    >>
    >> and its simple, if one works remotely one has their IP in an ACL, and only
    >> those in postion of trust will ever get that privilidge.
    >>
    >>>>> local exploits = minimal risk

    >
    >
    > While I understand what Keith is saying, I'm largely in agreement with Res
    > on this. For home users, this local kernel exploit is simply a non-issue,
    > and anyone saying otherwise should probably be referred to as Chicken Little.
    > ** okay, maybe a *few* home users, but you get the point ** :-)
    >
    > For mission-critical servers and such, only admins will generally have ssh
    > or console access anyway, so again, it's a non-issue.
    >
    > For ISP's, universities, and other such entities that have untrusted users
    > with accounts on a box, this is very much an issue. Those people, however,
    > were not here fussing - they were busy fixing their boxes to prevent the
    > exploit from affecting them (more).


    I'm in such a position, yet I'm still fussing.

    Res' position is perfectly acceptable for the home-user and
    mission-critical situations you describe, but what I am fussing about is
    his complete disregard for the possibility of your ISP/university/many
    ssh users scenario. These machines *do* exist, most of them for good
    reason, and forcing users to gain ''trust'' (what is that? I barely
    trust myself as root sometimes) and record every IP in some iptables
    or tcpwrappers rule is not feasible. So to simply blow off a local root
    exploit is to blow off all these sites, and to say "you deserve what you
    get" is a denial of how the world works. Sure, I'd love to know and
    trust every one of my local users, but in my position that's simply not
    going to happen, and I have to deal with it.

    (That being said, it's not something I'm paranoid over; it's not
    something I would feel needs to be patched immediately, and I can go
    through my normal routine of alerting my users and scheduling a block of
    downtime. Only a remote root exploit would I patch first and alert
    users later.)

    --keith



    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  3. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-13, Keith Keller wrote:
    > On 2008-02-13, Robby Workman wrote:
    >>
    >> While I understand what Keith is saying, I'm largely in agreement with Res
    >> on this. For home users, this local kernel exploit is simply a non-issue,
    >> and anyone saying otherwise should probably be referred to as Chicken Little.
    >> ** okay, maybe a *few* home users, but you get the point ** :-)
    >>
    >> For mission-critical servers and such, only admins will generally have ssh
    >> or console access anyway, so again, it's a non-issue.
    >>
    >> For ISP's, universities, and other such entities that have untrusted users
    >> with accounts on a box, this is very much an issue. Those people, however,
    >> were not here fussing - they were busy fixing their boxes to prevent the
    >> exploit from affecting them (more).

    >
    > I'm in such a position, yet I'm still fussing.
    >
    > Res' position is perfectly acceptable for the home-user and
    > mission-critical situations you describe, but what I am fussing about is
    > his complete disregard for the possibility of your ISP/university/many
    > ssh users scenario.



    Yeah, I know I was trying to bridge the gap between what he was
    saying and what you were saying. I guess I partially failed :-)

    -RW

  4. Re: [security] Local Root Explot for Kernel 2.6.21!

    On Wed, 13 Feb 2008, Keith Keller wrote:

    > Res' position is perfectly acceptable for the home-user and
    > mission-critical situations you describe, but what I am fussing about is
    > his complete disregard for the possibility of your ISP/university/many
    > ssh users scenario. These machines *do* exist, most of them for good


    I speak of ISP situations, maybe its just my country? but nobody runs
    shell servers for end users anymore except for the uni's, but they are so
    locked down in ports at border routers its not overly an issue for them
    to run it, but general ISP/Telcos not for 6,7,8 years or more now for much
    the same reason this thread is about, 'abuse of trust', and I seriously
    can't see someone like ATT or Sprint etc offering shells But maybe they
    do? or is it just the smaller ISP's over there?


    --
    Cheers
    Res

    mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

  5. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-13, Res wrote:
    >
    > I speak of ISP situations, maybe its just my country? but nobody runs
    > shell servers for end users anymore except for the uni's, but they are so
    > locked down in ports at border routers its not overly an issue for them
    > to run it, but general ISP/Telcos not for 6,7,8 years or more now for much
    > the same reason this thread is about, 'abuse of trust', and I seriously
    > can't see someone like ATT or Sprint etc offering shells But maybe they
    > do? or is it just the smaller ISP's over there?


    In general, universities in the US do not have strict controls at the
    border routers. They might block nonstandard and/or unprivileged ports,
    but they don't typically block incoming ssh by default, for the very
    reasons I cited: faculty run their own servers, and need to grant
    collaborators unpredictable sshd access. Some schools may block some
    buildings (e.g., student dorms) more thoroughly than others, and other
    schools may simply block practically everything as a matter of policy.

    My own ISP, Speakeasy, does run a general-purpose box for users to ssh
    into. You need to request the account specifically, but it's available
    for any users. (This may have changed since they got gobbled by Best
    Buy. Best Buy?!?) From my understanding SE is not a small-time ISP,
    though certainly not as behemoth as AT&T.

    Point being, there are many general-purpose servers out there that need
    to support ssh for dozens or hundreds of potentially untrusted users, so
    for those sites a local root exploit is important to patch; its
    importance increases (probably exponentially) with the number of users
    it supports.

    Grander point being, we all should not assume that a particular use case
    can't arise in everyday applications, as we never know what some
    organization is doing with linux. Often discussion topics center around
    the median usage, not sufficiently taking into account the extremes; for
    example, discussion about disk use often disregards the embedded arena
    (where disk, being all in RAM, is at a premium) and the high-end
    (petabyte disk arrays, while not widespread, are becoming more more
    common).

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  6. Re: [security] Local Root Explot for Kernel 2.6.21!

    On Wed, 13 Feb 2008, Keith Keller wrote:

    > In general, universities in the US do not have strict controls at the
    > border routers. They might block nonstandard and/or unprivileged ports,
    > but they don't typically block incoming ssh by default, for the very
    > reasons I cited: faculty run their own servers, and need to grant
    > collaborators unpredictable sshd access. Some schools may block some
    > buildings (e.g., student dorms) more thoroughly than others, and other
    > schools may simply block practically everything as a matter of policy.
    >
    > My own ISP, Speakeasy, does run a general-purpose box for users to ssh
    > into. You need to request the account specifically, but it's available
    > for any users. (This may have changed since they got gobbled by Best
    > Buy. Best Buy?!?) From my understanding SE is not a small-time ISP,
    > though certainly not as behemoth as AT&T.


    I can see your point now, but I guess that's not a concern in this country
    since no one does it anymore, but obviously has its merits in other parts
    of the world where open access in permitted.

    Do the ISP's there allow you access to the server from off-network?
    I am curious if these use any security or allow world access, if the
    former I can accept that since you'd have to be on their network ranges
    and can easily be 'culled off' in more ways than just one too hehe if you
    do something norty, if its the latter, thats plain suicide IMHO.


    --
    Cheers
    Res

    mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

  7. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-13, Res wrote:
    >
    > Do the ISP's there allow you access to the server from off-network?


    I haven't used my ISP's shell access in some time, but when I did I
    could log in from any machine I tried. I never left US networks,
    though, so I have no idea if they deny access from foreign IPs.

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  8. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-13, Res wrote:
    >
    > Do the ISP's there allow you access to the server from off-network?
    > I am curious if these use any security or allow world access, if the
    > former I can accept that since you'd have to be on their network ranges
    > and can easily be 'culled off' in more ways than just one too hehe if you
    > do something norty, if its the latter, thats plain suicide IMHO.
    >
    >


    I have an isp account with a west coast organization that not only allows
    ssh access from any machine, but also allows telnet access. They've been
    around for 20 years so I assume they know what they're doing.

    Actually, there was an old time ISP locally that allowed ssh and telnet,
    from any machine since the early 90's - maybe before that

    ken

  9. Re: [security] Local Root Explot for Kernel 2.6.21!

    On Wed, 13 Feb 2008, Keith Keller wrote:

    > I haven't used my ISP's shell access in some time, but when I did I
    > could log in from any machine I tried. I never left US networks,
    > though, so I have no idea if they deny access from foreign IPs.


    That's still very scary We used to do it 8 years ago, but only allowed
    our IP ranges, some universities over here however allow world access, and
    some others provide a private dial bank into an annex for students not on
    campus, mind you, most the unis here use AIX or slowaris.


    --
    Cheers
    Res

    mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

  10. Re: [security] Local Root Explot for Kernel 2.6.21!

    On Wed, 13 Feb 2008, No_One wrote:

    > ssh access from any machine, but also allows telnet access. They've been
    > around for 20 years so I assume they know what they're doing.


    assumption can be the death of you, but then again, your own users are
    not likely to attack your own machine

    --
    Cheers
    Res

    mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

  11. Re: [security] Local Root Explot for Kernel 2.6.21!

    On 2008-02-14, Res wrote:
    > On Wed, 13 Feb 2008, No_One wrote:
    >
    >> ssh access from any machine, but also allows telnet access. They've been
    >> around for 20 years so I assume they know what they're doing.

    >
    > assumption can be the death of you, but then again, your own users are
    > not likely to attack your own machine
    >


    yeah, true enough...one of the five horsemen of the apocalyse, war, famine,
    death, pestilence and assumption.

    ken

  12. Re: [security] Local Root Explot for Kernel 2.6.21!

    Robby Workman wrote:
    > So many of the "security" bugs that arise are of questionable impact.
    > That's not to say that they're not issues - they clearly are - but when
    > a potential vulnerability does not published exploit code


    ... then there still is a good chance, an attacker may easily create the
    exploit code, he needs.

    CU

    Manuel


  13. Re: [security] Local Root Explot for Kernel 2.6.21!

    +Alan Hicks+ wrote:
    > As some one who was involved in the SlackSec project that you seem to
    > have thought so highly of (thank you for your recommendation, btw), I
    > think I'm in a good position to say that *nobody* in his right mind
    > wants this job.


    I've taken all patches for the X-Server from gentoo, patched the server
    and recompiled the package. I also updated my xine-lib library. This
    way, all issuses, I still see, are currently fixed for me.

    At least I feel better if holes like this are closed:
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2006-1664
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-0486
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-4568
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-5760
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-5958
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-6427
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-6428
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-6429
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-0006

    As an end user it's pretty difficult for me to believe, that all those
    holes aren't critical, if nearly all distributions have published
    patches for them.

    As I have to port this packages to several more computers, some of them
    only accessible via internet, I'll have to get webspace to publish my
    updates to them and as it sucks to auto-fetch updates from different
    servers, I'll also mirror all the official patches on this server.

    This way, I either get a nice update system, which allowes me to publish
    update packages, I'll create using gentoo patches, where available, to
    the computers, I have to manage or I'll finally have to realize that all
    this is too much trouble.

    "Learning by doing" ;-)

    CU

    Manuel


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2