Re: [Full-disclosure] Kevin Johnson BASE <= 1.3.6 authentication bypass
hey kitty's!
please, keep your non-technical bullshit offlist.
i have made very clear what is vulnerable and what is not
where it is and how to reproduce it.
so stop bullshitting and go get some milk.
On 6/5/07, Kradorex Xeron <[EMAIL PROTECTED]> wrote:
> I'm not going to bother commenting on your specific sections, so I'll top-post
> so as not to expose people to the bad content of the previous message:
>
> Okay...
> 1. You claim this is "Full Disclosure" yet you fail to disclose alot of the
> information required to make an accurate advisory, THEN you proceed to tell
> people to google for it themselves. If you post it in that context, What
> relevance is your "advisory"? Why did you post it at all if you supply little
> to no source information, and no proof? Without that information,
> this "advisory" is useless.
>
> 2. This is a list designed for professionals and those who know what they're
> talking about in a "loosened up" environment that we don't feel we'll get
> moderated for stuff we post.
>
> 3. You then proceed to use someone else's name to do what exactly? Your
> attempts at defaming Kevin Johnson made you yourself defamed instead as it
> makes you appear egotistical and trying to bring someone else down for your
> own glory. You failed.
>
> 4. While on this list, Try to speak professionally, and don't talk like you're
> some script kiddie that's urging to get some glory. From my perspective,
> that's what you are doing. If you don't want to be interpreted as that, use
> good form, dont' use "STFU", "LOL" and/or such more than one time per post.
>
> Thank you,
> Krad Xeron
>
> On Tuesday 05 June 2007 13:48, Johnny Storm wrote:
> > >I think your "vulnerability report" sucks (to use your word.)
> > >1) You use very unprofessional language
> >
> > ghhh.
> >
> > >2) You provide no links to either Base or the Base+ fork so the reader can
> > >check for themselves.
> >
> > learn to read or to use google. (whats on the same top of my posting?)
> >
> > >3) You provide no source from the Base+ fork to show how its
> > >authentication scheme is not vulnerable
> >
> > it's open source. go - check it yourself.
> >
> > >4) You personalize your report by using Kevin's name, in an attempt to
> > >embarrass him
> >
> > it seems that you haven't yet noticed what is the name
> > of his *security* product ;-)
> >
> > >5) You provide no evidence that you have ever contacted the Base project
> > >and notified them of your "discovery"
> >
> > full disclosure.
> >
> > >6) You don't even mention that an authentication vulnerability was
> > >**reported and fixed** more than a year ago, nor do you mention how your
> > >report relates to that vulnerability [1][2][3]
> >
> > you haven't done your homework. this vulnerability has nothing
> > to do with those you discovered.
> >
> > >7) You don't explain that the code you posted is not part of the
> > >authentication system and that the auth code is in base_auth_inc.php.
> >
> > learn to read. lol.
> >
> > >8) You don't explain what you mean by "what if not?" The answer is, if
> > >not, then authentication is required, you do have a role and you have
> > >already authenticated.
> >
> > at this point you prove that you have no clue.
> > please, stfu and go offlist noob.
> >
> > On 6/5/07, Paul Schmehl <[EMAIL PROTECTED]> wrote:
> > > --On June 4, 2007 10:35:40 PM +0300 Johnny Storm <[EMAIL PROTECTED]>
> > >
> > > wrote:
> > > > Basic Analysis and Security Engine (BASE)
> > > > (http://base.secureideas.net/)
> > > >
> > > >
> > > > One more security product with lame bugs...
> > > >
> > > > Let's look at Kevin's authentication code,
> > > > for example in base_main.php (all pages vulnerable):
> > > >
> > > > [...]
> > > > 64 // Check role out and redirect if needed -- Kevin
> > > > 65 $roleneeded = 1;
> > > > 66 $BUser = new BaseUser();
> > > > 67 //if (($Use_Auth_System == 1) && ($BUser->hasRole($roleneeded)
> > > > == 0)) 68 if ($Use_Auth_System == 1)
> > > > 69 {
> > > > 70 if ($BUser->hasRole($roleneeded) == 0)
> > > > 71 {
> > > > 72 header("Location: $BASE_urlpath/index.php");
> > > > 73 }
> > > > 74 }
> > > > [...]
> > > >
> > > > Where is bug?
> > > > Yes, your browser will redirect after received location header,
> > > > but what if not? ;-)
> > > >
> > > > Test with curl. This is not first authentication issue in BASE,
> > > > putting at risk users which use BASE authentication feature.
> > > > Google shows up many installations protected by this feature.
> > > >
> > > > All BASE versions with authentication are vulnerable.
> > > > ACID is not vulnerable, since it doesn't has such feature.
> > > > BASE+ fork has fixed this issue year ago.
> > > >
> > > > Use your web server authentication or BASE+, which sucks less.
> > >
> > > I think your "vulnerability report" sucks (to use your word.)
> > > 1) You use very unprofessional language
> > > 2) You provide no links to either Base or the Base+ fork
[Full-disclosure] [USN-469-1] Thunderbird vulnerabilities
=== Ubuntu Security Notice USN-469-1 June 05, 2007 mozilla-thunderbird vulnerabilities CVE-2007-1558, CVE-2007-2867, CVE-2007-2868 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 6.10 Ubuntu 7.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: mozilla-thunderbird 1.5.0.12-0ubuntu0.6.06 Ubuntu 6.10: mozilla-thunderbird 1.5.0.12-0ubuntu0.6.10 Ubuntu 7.04: mozilla-thunderbird 1.5.0.12-0ubuntu0.7.04 After a standard system upgrade you need to restart Thunderbird to effect the necessary changes. Details follow: Gaëtan Leurent showed a weakness in APOP authentication. An attacker posing as a trusted server could recover portions of the user's password via multiple authentication attempts. (CVE-2007-1558) Various flaws were discovered in the layout and JavaScript engines. By tricking a user into opening a malicious email, an attacker could execute arbitrary code with the user's privileges. Please note that JavaScript is disabled by default for emails, and it is not recommended to enable it. (CVE-2007-2867, CVE-2007-2868) Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12-0ubuntu0.6.06.diff.gz Size/MD5: 455017 6134996c92b001015b30150c2dc1ebc9 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12-0ubuntu0.6.06.dsc Size/MD5: 1603 a28b5d142a6f31040ed31e9a6d6bc89f http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12.orig.tar.gz Size/MD5: 36087822 b4da2245a3b9e9aba57458892ccb4432 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-dev_1.5.0.12-0ubuntu0.6.06_amd64.deb Size/MD5: 3536144 14ea0a1977a5320fd835fd001d67346f http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-inspector_1.5.0.12-0ubuntu0.6.06_amd64.deb Size/MD5: 194244 8b458963ac0651ed0cd6391eff22 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-typeaheadfind_1.5.0.12-0ubuntu0.6.06_amd64.deb Size/MD5:59492 f72ea0bdf598e970be1fc2bc4c13aca5 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12-0ubuntu0.6.06_amd64.deb Size/MD5: 12072898 5c56a62ecebbd04b0d5800e02bb0f962 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-dev_1.5.0.12-0ubuntu0.6.06_i386.deb Size/MD5: 3529200 7e19aa6138e8feed5cff6d838b6028a9 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-inspector_1.5.0.12-0ubuntu0.6.06_i386.deb Size/MD5: 187602 6820a2a671a38afd15a0f6a85d836e1a http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-typeaheadfind_1.5.0.12-0ubuntu0.6.06_i386.deb Size/MD5:55014 7bafe57ee68339de3cd6b652b38f732e http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12-0ubuntu0.6.06_i386.deb Size/MD5: 10348548 b9681e3ee16c04c08339ec2ef01a6c88 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-dev_1.5.0.12-0ubuntu0.6.06_powerpc.deb Size/MD5: 3534496 3c48628681299abaee19fc0beba5ab78 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-inspector_1.5.0.12-0ubuntu0.6.06_powerpc.deb Size/MD5: 190946 fbbcce5b8063cb919394a9eb6606be14 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-typeaheadfind_1.5.0.12-0ubuntu0.6.06_powerpc.deb Size/MD5:58594 feced950d4786dca229a3311d78ebd92 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird_1.5.0.12-0ubuntu0.6.06_powerpc.deb Size/MD5: 11625662 84c92da6096228d1e9d9b88bd7b04175 sparc architecture (Sun SPARC/UltraSPARC) http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-dev_1.5.0.12-0ubuntu0.6.06_sparc.deb Size/MD5: 3531010 bcc28364913ee9a39fcbe927c18c63b6 http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-inspector_1.5.0.12-0ubuntu0.6.06_sparc.deb Size/MD5: 188396 269be710a7fba93ef6b097b2b9fff9db http://security.ubuntu.com/ubuntu/pool/main/m/mozilla-thunderbird/mozilla-thunderbird-typeaheadfind_1.5.0.12-0ubuntu0.6.06_sparc.deb
[Full-disclosure] [ MDKSA-2007:117 ] - Updated lha packages fix unsafe temporary files creation issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:117 http://www.mandriva.com/security/ ___ Package : lha Date: June 5, 2007 Affected: 2007.0, 2007.1, Corporate 3.0, Corporate 4.0 ___ Problem Description: lharc.c in lha does not securely create temporary files, which might allow local users to read or write files by creating a file before LHA is invoked. Updated packages have been patched to prevent this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2030 ___ Updated Packages: Mandriva Linux 2007.0: 1a86c72a37b9b75f20a1846afe078b7c 2007.0/i586/lha-1.14i-12.1mdv2007.0.i586.rpm e59b67dcbf26ce47367ad72392c02703 2007.0/SRPMS/lha-1.14i-12.1mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 8b9b38a7af95e1c9b2736fad57072055 2007.0/x86_64/lha-1.14i-12.1mdv2007.0.x86_64.rpm e59b67dcbf26ce47367ad72392c02703 2007.0/SRPMS/lha-1.14i-12.1mdv2007.0.src.rpm Mandriva Linux 2007.1: 2939b2af40f5d40ac7825ae8574b578e 2007.1/i586/lha-1.14i-12.1mdv2007.1.i586.rpm fcf1366bdb3b01a0380f2f69a264f5dc 2007.1/SRPMS/lha-1.14i-12.1mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: e74b2ff470799f29d4f4ab4abd98cf2e 2007.1/x86_64/lha-1.14i-12.1mdv2007.1.x86_64.rpm fcf1366bdb3b01a0380f2f69a264f5dc 2007.1/SRPMS/lha-1.14i-12.1mdv2007.1.src.rpm Corporate 3.0: 751fdee1c1570cf7ca69e5615d54256a corporate/3.0/i586/lha-1.14i-11.1.C30mdk.i586.rpm e7a018aec6d42cf0c5dc04e05fd60d02 corporate/3.0/SRPMS/lha-1.14i-11.1.C30mdk.src.rpm Corporate 3.0/X86_64: 449a040f7019656ef825527791a40255 corporate/3.0/x86_64/lha-1.14i-11.1.C30mdk.x86_64.rpm e7a018aec6d42cf0c5dc04e05fd60d02 corporate/3.0/SRPMS/lha-1.14i-11.1.C30mdk.src.rpm Corporate 4.0: d1dc05e42fed62f99cfcc17760b345f0 corporate/4.0/i586/lha-1.14i-11.1.20060mlcs4.i586.rpm c1448318b2a31a5b6654a12113ef7d70 corporate/4.0/SRPMS/lha-1.14i-11.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: a8835efff6d4124ede93111512f04685 corporate/4.0/x86_64/lha-1.14i-11.1.20060mlcs4.x86_64.rpm c1448318b2a31a5b6654a12113ef7d70 corporate/4.0/SRPMS/lha-1.14i-11.1.20060mlcs4.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGZhl7mqjQ0CJFipgRAn1qAKCpKFYL4L2hqkWddpFcC9MSKmUIcwCgw3Il lloGhPv2KPR/cTwu3lJntgY= =4M4s -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Whats wrong with milw0rm forums?
does any1 know what's wrong with milw0rm forums? i can't find the http://forums.milw0rm.com login page, repair? - mark ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Hello !
You know what, pay everyone on full-disclosure a dollar for mentioning an ActiveX bug, and we will call it even. Shirkdog ' or 1=1-- http://www.shirkdog.us >From: [EMAIL PROTECTED] >To: ene0toue ene0toue <[EMAIL PROTECTED]> >CC: full-disclosure@lists.grok.org.uk >Subject: Re: [Full-disclosure] Hello ! >Date: Tue, 05 Jun 2007 19:47:14 -0400 > >On Tue, 05 Jun 2007 16:29:43 PDT, ene0toue ene0toue said: > > > Hello I Find A ZeroDay Vuln in Activex , Want to Buy ? It > > Null-Pointer-Defererene But If User Has No Ms06-51 , ActivX Is Exploit >! > >How "zero day" can it be if a patch released last year prevents it from >working? ><< attach4 >> >___ >Full-Disclosure - We believe in it. >Charter: http://lists.grok.org.uk/full-disclosure-charter.html >Hosted and sponsored by Secunia - http://secunia.com/ _ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Hello !
On Tue, 05 Jun 2007 16:29:43 PDT, ene0toue ene0toue said: > Hello I Find A ZeroDay Vuln in Activex , Want to Buy ? It > Null-Pointer-Defererene But If User Has No Ms06-51 , ActivX Is Exploit ! How "zero day" can it be if a patch released last year prevents it from working? pgp0nhZwZxYV2.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Cacti Denial of Service
Description:
---
It is possible to an authenticated user in Cacti to modify the
graph_start and graph_end parameters values in the URL, and specify
higher numbers than expected in order to make Cacti use all the server CPU.
For example, if an user modify a graph URL as seen is the location bar:
http://localhost/cacti/graph_image.php?local_graph_id=2&rra_id=0&view_type=tree&graph_start=1164236234&graph_end=1179871034
to this one:
http://localhost/cacti/graph_image.php?local_graph_id=2&rra_id=0&view_type=tree&graph_start=1164236234000&graph_end=1179871034000
rrdtool will take 100% of the CPU (for a long time). By doing multiple
requests like this, an attacker may create a denial of service on the
server running Cacti.
This was tested on the current version, but should work on previous
versions as well.
Solution:
You should ùodify the check done in the file lib/html_validate.php
(function input_validate_input_number) by adding a second check like this:
function input_validate_input_number($value) {
if ((!is_numeric($value)) && ($value != "")) {
die_html_input_error();
}
if ($value >= 100) {
die_html_input_error();
}
}
The Cacti team has now patched the source in their SVN :
http://svn.cacti.net/cgi-bin/viewcvs.cgi/branches/BRANCH_0_8_6/cacti/graph_image.php?rev=3956&r1=3898&r2=39
More info:
-
http://mdessus.free.fr/?p=15
http://bugs.cacti.net/view.php?id=955
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hello !
Hello I Find A ZeroDay Vuln in Activex , Want to Buy ? It Null-Pointer-Defererene But If User Has No Ms06-51 , ActivX Is Exploit ! - The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ MDKSA-2007:116 ] - Updated libpng packages fix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:116 http://www.mandriva.com/security/ ___ Package : libpng Date: June 5, 2007 Affected: 2007.0, 2007.1, Corporate 3.0, Corporate 4.0, Multi Network Firewall 2.0 ___ Problem Description: A flaw how libpng handled malformed images was discovered. An attacker able to create a carefully crafted PNG image could cause an application linked with libpng to crash when the file was manipulated. The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2445 http://www.cert.org/advisories/684664 ___ Updated Packages: Mandriva Linux 2007.0: 4483193885966f919f283594719a0a90 2007.0/i586/libpng3-1.2.12-2.3mdv2007.0.i586.rpm d13427f7a6494c82a8becec26aaa158f 2007.0/i586/libpng3-devel-1.2.12-2.3mdv2007.0.i586.rpm 86e2b902df20f46bbab8c198be7bb623 2007.0/i586/libpng3-static-devel-1.2.12-2.3mdv2007.0.i586.rpm 2351bce470227141eecf5a3adb303ce7 2007.0/SRPMS/libpng-1.2.12-2.3mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 80168137deb6e23d5a2fb6e8f3abc2ef 2007.0/x86_64/lib64png3-1.2.12-2.3mdv2007.0.x86_64.rpm b45baf5195b6ffd1d32b5829ff861b50 2007.0/x86_64/lib64png3-devel-1.2.12-2.3mdv2007.0.x86_64.rpm 9e4f1d18db609adc5c2f92629814e360 2007.0/x86_64/lib64png3-static-devel-1.2.12-2.3mdv2007.0.x86_64.rpm 2351bce470227141eecf5a3adb303ce7 2007.0/SRPMS/libpng-1.2.12-2.3mdv2007.0.src.rpm Mandriva Linux 2007.1: 300ed9a63f60a1ee16ce4e5caa71f96b 2007.1/i586/libpng3-1.2.13-2.1mdv2007.1.i586.rpm fdd3c3cefc587622382d37cd5fe2795e 2007.1/i586/libpng3-devel-1.2.13-2.1mdv2007.1.i586.rpm d6b13aa08877aec2aaf165203d2a6817 2007.1/i586/libpng3-static-devel-1.2.13-2.1mdv2007.1.i586.rpm 00e882bf543c8730d656417304f3b4e1 2007.1/SRPMS/libpng-1.2.13-2.1mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: f1289336b45eb58bc2975011086fbfa9 2007.1/x86_64/lib64png3-1.2.13-2.1mdv2007.1.x86_64.rpm 8dc0504ac8c6ed8e6c5f641c738df144 2007.1/x86_64/lib64png3-devel-1.2.13-2.1mdv2007.1.x86_64.rpm d0b9f63131ecbfe01db295d15903fd40 2007.1/x86_64/lib64png3-static-devel-1.2.13-2.1mdv2007.1.x86_64.rpm 00e882bf543c8730d656417304f3b4e1 2007.1/SRPMS/libpng-1.2.13-2.1mdv2007.1.src.rpm Corporate 3.0: 9c0077ae596e6a2340ed6e08ab6c437c corporate/3.0/i586/libpng3-1.2.5-10.8.C30mdk.i586.rpm 2f44c9f5639aff57948b64cf845efa39 corporate/3.0/i586/libpng3-devel-1.2.5-10.8.C30mdk.i586.rpm e1638f0497b35341796bb74ccb5a95e7 corporate/3.0/i586/libpng3-static-devel-1.2.5-10.8.C30mdk.i586.rpm 5905453feaf135e67bbdf4fecbc55335 corporate/3.0/SRPMS/libpng-1.2.5-10.8.C30mdk.src.rpm Corporate 3.0/X86_64: 632b1254a5b2ee4def5ac2f98bc7bd4c corporate/3.0/x86_64/lib64png3-1.2.5-10.8.C30mdk.x86_64.rpm b4ad3f3a34be89a22c7bdfcb8b9f351d corporate/3.0/x86_64/lib64png3-devel-1.2.5-10.8.C30mdk.x86_64.rpm 419f3faddaeb3cbfa3ca020630858682 corporate/3.0/x86_64/lib64png3-static-devel-1.2.5-10.8.C30mdk.x86_64.rpm 5905453feaf135e67bbdf4fecbc55335 corporate/3.0/SRPMS/libpng-1.2.5-10.8.C30mdk.src.rpm Corporate 4.0: a444aa0f9b3c0e5bac0562b3274806a5 corporate/4.0/i586/libpng3-1.2.8-1.3.20060mlcs4.i586.rpm 25542984f9b920e9ab9197d383c201b9 corporate/4.0/i586/libpng3-devel-1.2.8-1.3.20060mlcs4.i586.rpm a0c238ea1c16f892b704b5055fcc340d corporate/4.0/i586/libpng3-static-devel-1.2.8-1.3.20060mlcs4.i586.rpm 9442bef36dbda9e9518ce367a7569d90 corporate/4.0/SRPMS/libpng-1.2.8-1.3.20060mlcs4.src.rpm Corporate 4.0/X86_64: 2ff58096a6a2961e15719aa35107fda6 corporate/4.0/x86_64/lib64png3-1.2.8-1.3.20060mlcs4.x86_64.rpm 78ecdacb1033eecfbf48e464d3106bb1 corporate/4.0/x86_64/lib64png3-devel-1.2.8-1.3.20060mlcs4.x86_64.rpm 85ee7effc74676da27c1c2c1219b97a7 corporate/4.0/x86_64/lib64png3-static-devel-1.2.8-1.3.20060mlcs4.x86_64.rpm 9442bef36dbda9e9518ce367a7569d90 corporate/4.0/SRPMS/libpng-1.2.8-1.3.20060mlcs4.src.rpm Multi Network Firewall 2.0: ea358d9ef4e412851f89abac96d015b7 mnf/2.0/i586/libpng3-1.2.5-10.8.M20mdk.i586.rpm 3068b2316e8225377b88dcaedbadb878 mnf/2.0/SRPMS/libpng-1.2.5-10.8.M20mdk.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Li
[Full-disclosure] [ MDKSA-2007:114 ] - Updated file packages fix vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:114 http://www.mandriva.com/security/ ___ Package : file Date: June 5, 2007 Affected: 2007.0, 2007.1, Corporate 3.0, Corporate 4.0, Multi Network Firewall 2.0 ___ Problem Description: The update to correct CVE-2007-1536 (MDKSA-2007:067), a buffer overflow in the file_printf() function, introduced a new integer overflow as reported by Colin Percival. This flaw, if an atacker could trick a user into running file on a specially crafted file, could possibly lead to the execution of arbitrary code with the privileges of the user running file (CVE-2007-2799). As well, in file 4.20, flawed regular expressions to identify OS/2 REXX files could lead to a denial of service via CPU consumption (CVE-2007-2026). The updated packages have been patched to correct these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2026 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2799 ___ Updated Packages: Mandriva Linux 2007.0: 3da3923de6da550bab34801eef616c65 2007.0/i586/file-4.17-2.2mdv2007.0.i586.rpm cdda9efd3b6b29b3bd959c27b9b4ff45 2007.0/i586/libmagic1-4.17-2.2mdv2007.0.i586.rpm 7a7639ae8578d60800a3606ea7846046 2007.0/i586/libmagic1-devel-4.17-2.2mdv2007.0.i586.rpm b88d355059a7abaa684ca4ccd2902f5e 2007.0/i586/libmagic1-static-devel-4.17-2.2mdv2007.0.i586.rpm 8be4b2fc01aae6687cea3d32bf13adec 2007.0/i586/python-magic-4.17-2.2mdv2007.0.i586.rpm 0faac11bd3ceb07623dcc538259b4920 2007.0/SRPMS/file-4.17-2.2mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 7b236e74e29e7322a63db012508f4ff7 2007.0/x86_64/file-4.17-2.2mdv2007.0.x86_64.rpm c9ee191afb3c4f13989aecc4c0550a64 2007.0/x86_64/lib64magic1-4.17-2.2mdv2007.0.x86_64.rpm 895f9822301c950fa52b34a8f1e6458d 2007.0/x86_64/lib64magic1-devel-4.17-2.2mdv2007.0.x86_64.rpm a667f8207f61a7407ad3434e779cd2a3 2007.0/x86_64/lib64magic1-static-devel-4.17-2.2mdv2007.0.x86_64.rpm 87b499c21853acc87c968c6a24a5f0d4 2007.0/x86_64/python-magic-4.17-2.2mdv2007.0.x86_64.rpm 0faac11bd3ceb07623dcc538259b4920 2007.0/SRPMS/file-4.17-2.2mdv2007.0.src.rpm Mandriva Linux 2007.1: 0f340f48900656e4d393c26f41cfd24a 2007.1/i586/file-4.20-1.1mdv2007.1.i586.rpm d690cf39a2b9d4bce78eb3ba76f89034 2007.1/i586/libmagic1-4.20-1.1mdv2007.1.i586.rpm adf38bdec1118a46cbc8063cd1c87bfd 2007.1/i586/libmagic1-devel-4.20-1.1mdv2007.1.i586.rpm 7f650e75b6bcbfee83f356e6a39f5d8b 2007.1/i586/libmagic1-static-devel-4.20-1.1mdv2007.1.i586.rpm d5556e8963b4f8e3750a8c2b4844f3cb 2007.1/i586/python-magic-4.20-1.1mdv2007.1.i586.rpm 4335066ac789ab04b344be24e80f26c7 2007.1/SRPMS/file-4.20-1.1mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: 649ff715c11ed4de3233ac50f1cf0773 2007.1/x86_64/file-4.20-1.1mdv2007.1.x86_64.rpm a5c7e2604290b2523288614191ecb153 2007.1/x86_64/lib64magic1-4.20-1.1mdv2007.1.x86_64.rpm 239042ad851510f9e66e3c03067e3129 2007.1/x86_64/lib64magic1-devel-4.20-1.1mdv2007.1.x86_64.rpm a8597d9708ea995c85ae640b468ed43a 2007.1/x86_64/lib64magic1-static-devel-4.20-1.1mdv2007.1.x86_64.rpm f13b9cb6c65c4247a66a18b32f02a253 2007.1/x86_64/python-magic-4.20-1.1mdv2007.1.x86_64.rpm 4335066ac789ab04b344be24e80f26c7 2007.1/SRPMS/file-4.20-1.1mdv2007.1.src.rpm Corporate 3.0: 1df48d0c9911aa0bb1ffd7cd6541841a corporate/3.0/i586/file-4.07-3.2.C30mdk.i586.rpm a874520fc37514088e859482cecc1e74 corporate/3.0/i586/libmagic1-4.07-3.2.C30mdk.i586.rpm 45f463521c4a48a6fe5a94af29c0bf08 corporate/3.0/i586/libmagic1-devel-4.07-3.2.C30mdk.i586.rpm 8d2c8f7eafc9a606913c0d4ec5e4398c corporate/3.0/i586/libmagic1-static-devel-4.07-3.2.C30mdk.i586.rpm f3f6d9560bd1ef14795abec51391e776 corporate/3.0/SRPMS/file-4.07-3.2.C30mdk.src.rpm Corporate 3.0/X86_64: 554baaf5942ac5e533e72812394fc6ec corporate/3.0/x86_64/file-4.07-3.2.C30mdk.x86_64.rpm 5880184431f8918886543337a43f19d5 corporate/3.0/x86_64/lib64magic1-4.07-3.2.C30mdk.x86_64.rpm a1c8b2cd7a721e1429f3a4cd855b0235 corporate/3.0/x86_64/lib64magic1-devel-4.07-3.2.C30mdk.x86_64.rpm b56eba4a34a18ea5df00a1bfbd103b91 corporate/3.0/x86_64/lib64magic1-static-devel-4.07-3.2.C30mdk.x86_64.rpm f3f6d9560bd1ef14795abec51391e776 corporate/3.0/SRPMS/file-4.07-3.2.C30mdk.src.rpm Corporate 4.0: 0a2f24f69b886df7c5439dd4726bae7a corporate/4.0/i586/file-4.14-2.3.20060mlcs4.i586.rpm cf7484c68d78b2888290ed83ca69b2f7 corporate/4.0/i586/libmagic1-4.14-2.3.20060mlcs4.i586.rpm 4f71702b0528d8cb8f3a999043a37b60 corporate/4.0/i586/libmagic1-devel-4.14-2.3.20060mlcs4.i586.rpm 05d475851788a
Re: [Full-disclosure] Assorted browser vulnerabilities
The 522+ stuff I can confirm as vulnerable. That particular build number is associated with the current version of the "nightly" webkit build. http://nightly.webkit.org/ 419.3 is associated with the current Security updates on 10.4.9 I am pretty sure. -KF On Jun 5, 2007, at 2:08 PM, Michal Zalewski wrote: > On Mon, 4 Jun 2007, Michal Zalewski wrote: > >> 1) Title: MSIE page update race condition >>Impact : cookie stealing / setting, page hijacking, memory >> corruption >>Demo : http://lcamtuf.coredump.cx/ierace/ > > Just FYI - my logs indicate that there is a fairly high percentage of > patterns consistent with successful exploitation among Safari users > (about > 20%). > > For the non-vulnerable Firefox, this value is at 1% (for spoofed > User-Agent strings, random pranks, etc). > > As such, the value for Safari seems significant, particularly since > this > PoC is timing-dependent and fine-tuned for MSIE. I have no > immediate way > to test it, but feel encouraged to explore this further. > > /mz > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Macro threats
Muscarella, Sebastian (IT) wrote: > > > NOTICE: If received in error, please destroy and notify sender. Sender > does not intend to waive confidentiality or privilege. Use of this email > is prohibited when received in error. > > > > 1. Shouldn't I destroy the sender *after* notifying him? 2. You may not intend to waive confidentiality or privilege, but you did. 3. You can't prohibit what I do with this email. It is mine now. Moohahaha! Seriously. These tags piss me off. There is no legal justification. It just makes the company's admins look like uneducated asses. I encourage all organizations to accept the fact that your emails are community property once you hit send. There is no e-mail Postal police nor should there be. Encrypt everything. Randy ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] ZDI-07-035: CA Multiple Product AV Engine CAB Header Parsing Stack Overflow Vulnerability
ZDI-07-035: CA Multiple Product AV Engine CAB Header Parsing Stack Overflow Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-07-035.html June 5, 2007 -- CVE ID: CVE-2007-2864 -- Affected Vendor: Computer Associates -- Affected Products: CA Anti-Virus eTrust EZ Antivirus CA Internet Security Suite 2007 eTrust Internet Security Suite eTrust EZ Armor CA Threat Manager CA Protection Suites CA Secure Content Manager CA Anti-Virus Gateway Unicenter Network and Systems Management BrightStor ARCserve Backup CA Common Services -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of various Computer Associates products. The specific flaw exists within the processing of an improperly defined "coffFiles" field in .CAB archives. Large values result in an unbounded data copy operation which can result in an exploitable stack-based buffer overflow. -- Vendor Response: Computer Associates has issued an update to correct this vulnerability. More details can be found at: http://supportconnectw.ca.com/public/antivirus/infodocs/caantivirus-securitynotice.asp -- Disclosure Timeline: 2007.02.16 - Vulnerability reported to vendor 2007.06.05 - Coordinated public release of advisory -- Credit: This vulnerability was discovered by an anonymous researcher. -- About the Zero Day Initiative (ZDI): Established by TippingPoint, a division of 3Com, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. 3Com does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, 3Com provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, 3Com provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is being sent by 3Com for the sole use of the intended recipient(s) and may contain confidential, proprietary and/or privileged information. Any unauthorized review, use, disclosure and/or distribution by any recipient is prohibited. If you are not the intended recipient, please delete and/or destroy all copies of this message regardless of form and any included attachments and notify 3Com immediately by contacting the sender via reply e-mail or forwarding to 3Com at [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] ZDI-07-034: CA Multiple Product AV Engine CAB Filename Parsing Stack Overflow Vulnerability
ZDI-07-034: CA Multiple Product AV Engine CAB Filename Parsing Stack Overflow Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-07-034.html June 5, 2007 -- CVE ID: CVE-2007-2863 -- Affected Vendor: Computer Associates -- Affected Products: CA Anti-Virus eTrust EZ Antivirus CA Internet Security Suite 2007 eTrust Internet Security Suite eTrust EZ Armor CA Threat Manager CA Protection Suites CA Secure Content Manager CA Anti-Virus Gateway Unicenter Network and Systems Management BrightStor ARCserve Backup CA Common Services -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability since November 30, 2006 by Digital Vaccine protection filter ID 4874. For further product information on the TippingPoint IPS: http://www.tippingpoint.com -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of various Computer Associates products. The specific flaw exists in the parsing of .CAB archives. When a long filename contained in the .CAB is processed by vete.dll an exploitable stack overflow may occur. -- Vendor Response: Computer Associates has issued an update to correct this vulnerability. More details can be found at: http://supportconnectw.ca.com/public/antivirus/infodocs/caantivirus-securitynotice.asp -- Disclosure Timeline: 2006.11.08 - Vulnerability reported to vendor 2006.11.30 - Digital Vaccine released to TippingPoint customers 2007.06.05 - Coordinated public release of advisory -- Credit: This vulnerability was discovered by an anonymous researcher. -- About the Zero Day Initiative (ZDI): Established by TippingPoint, a division of 3Com, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. 3Com does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, 3Com provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, 3Com provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is being sent by 3Com for the sole use of the intended recipient(s) and may contain confidential, proprietary and/or privileged information. Any unauthorized review, use, disclosure and/or distribution by any recipient is prohibited. If you are not the intended recipient, please delete and/or destroy all copies of this message regardless of form and any included attachments and notify 3Com immediately by contacting the sender via reply e-mail or forwarding to 3Com at [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Kevin Johnson BASE <= 1.3.6 authentication bypass
I'm not going to bother commenting on your specific sections, so I'll top-post
so as not to expose people to the bad content of the previous message:
Okay...
1. You claim this is "Full Disclosure" yet you fail to disclose alot of the
information required to make an accurate advisory, THEN you proceed to tell
people to google for it themselves. If you post it in that context, What
relevance is your "advisory"? Why did you post it at all if you supply little
to no source information, and no proof? Without that information,
this "advisory" is useless.
2. This is a list designed for professionals and those who know what they're
talking about in a "loosened up" environment that we don't feel we'll get
moderated for stuff we post.
3. You then proceed to use someone else's name to do what exactly? Your
attempts at defaming Kevin Johnson made you yourself defamed instead as it
makes you appear egotistical and trying to bring someone else down for your
own glory. You failed.
4. While on this list, Try to speak professionally, and don't talk like you're
some script kiddie that's urging to get some glory. From my perspective,
that's what you are doing. If you don't want to be interpreted as that, use
good form, dont' use "STFU", "LOL" and/or such more than one time per post.
Thank you,
Krad Xeron
On Tuesday 05 June 2007 13:48, Johnny Storm wrote:
> >I think your "vulnerability report" sucks (to use your word.)
> >1) You use very unprofessional language
>
> ghhh.
>
> >2) You provide no links to either Base or the Base+ fork so the reader can
> >check for themselves.
>
> learn to read or to use google. (whats on the same top of my posting?)
>
> >3) You provide no source from the Base+ fork to show how its
> >authentication scheme is not vulnerable
>
> it's open source. go - check it yourself.
>
> >4) You personalize your report by using Kevin's name, in an attempt to
> >embarrass him
>
> it seems that you haven't yet noticed what is the name
> of his *security* product ;-)
>
> >5) You provide no evidence that you have ever contacted the Base project
> >and notified them of your "discovery"
>
> full disclosure.
>
> >6) You don't even mention that an authentication vulnerability was
> >**reported and fixed** more than a year ago, nor do you mention how your
> >report relates to that vulnerability [1][2][3]
>
> you haven't done your homework. this vulnerability has nothing
> to do with those you discovered.
>
> >7) You don't explain that the code you posted is not part of the
> >authentication system and that the auth code is in base_auth_inc.php.
>
> learn to read. lol.
>
> >8) You don't explain what you mean by "what if not?" The answer is, if
> >not, then authentication is required, you do have a role and you have
> >already authenticated.
>
> at this point you prove that you have no clue.
> please, stfu and go offlist noob.
>
> On 6/5/07, Paul Schmehl <[EMAIL PROTECTED]> wrote:
> > --On June 4, 2007 10:35:40 PM +0300 Johnny Storm <[EMAIL PROTECTED]>
> >
> > wrote:
> > > Basic Analysis and Security Engine (BASE)
> > > (http://base.secureideas.net/)
> > >
> > >
> > > One more security product with lame bugs...
> > >
> > > Let's look at Kevin's authentication code,
> > > for example in base_main.php (all pages vulnerable):
> > >
> > > [...]
> > > 64 // Check role out and redirect if needed -- Kevin
> > > 65 $roleneeded = 1;
> > > 66 $BUser = new BaseUser();
> > > 67 //if (($Use_Auth_System == 1) && ($BUser->hasRole($roleneeded)
> > > == 0)) 68 if ($Use_Auth_System == 1)
> > > 69 {
> > > 70 if ($BUser->hasRole($roleneeded) == 0)
> > > 71 {
> > > 72 header("Location: $BASE_urlpath/index.php");
> > > 73 }
> > > 74 }
> > > [...]
> > >
> > > Where is bug?
> > > Yes, your browser will redirect after received location header,
> > > but what if not? ;-)
> > >
> > > Test with curl. This is not first authentication issue in BASE,
> > > putting at risk users which use BASE authentication feature.
> > > Google shows up many installations protected by this feature.
> > >
> > > All BASE versions with authentication are vulnerable.
> > > ACID is not vulnerable, since it doesn't has such feature.
> > > BASE+ fork has fixed this issue year ago.
> > >
> > > Use your web server authentication or BASE+, which sucks less.
> >
> > I think your "vulnerability report" sucks (to use your word.)
> > 1) You use very unprofessional language
> > 2) You provide no links to either Base or the Base+ fork so the reader
> > can check for themselves.
> > 3) You provide no source from the Base+ fork to show how its
> > authentication scheme is not vulnerable
> > 4) You personalize your report by using Kevin's name, in an attempt to
> > embarrass him
> > 5) You provide no evidence that you have ever contacted the Base project
> > and notified them of your "discovery"
> > 6) You don't even mention that an authentication vulnerability was
> > **reported and fixed** more than
[Full-disclosure] [ GLSA 200706-01 ] libexif: Integer overflow vulnerability
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200706-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: libexif: Integer overflow vulnerability Date: June 05, 2007 Bugs: #178081 ID: 200706-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis libexif fails to handle Exif (EXchangeable Image File) data inputs, making it vulnerable to an integer overflow. Background == libexif is a library for parsing, editing and saving Exif data. Affected packages = --- Package / Vulnerable / Unaffected --- 1 media-libs/libexif < 0.6.15>= 0.6.15 Description === Victor Stinner reported an integer overflow in the exif_data_load_data_entry() function from file exif-data.c while handling Exif data. Impact == An attacker could entice a user to process a file with specially crafted Exif extensions with an application making use of libexif, which will trigger the integer overflow and potentially execute arbitrary code or crash the application. Workaround == There is no known workaround at this time. Resolution == All libexif users should upgrade to the latest version. Please note that users upgrading from "<=media-libs/libexif-0.6.13" should also run revdep-rebuild after their upgrade. # emerge --sync # emerge --ask --oneshot --verbose ">=media-libs/libexif-0.6.15" # revdep-rebuild --library=/usr/lib/libexif.so References == [ 1 ] CVE-2007-2645 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2645 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200706-01.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 pgpOnUkNflKIN.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Macro threats
On Tue, 5 Jun 2007, Muscarella, Sebastian \(IT\) <[EMAIL PROTECTED]> wrote: > Wanted to ask this forum's opinion on the state of macro threats. While > we have not seen too many this past year which were actively exploited, > we wanted to know if there are any indications on whether this threat > would increase, decrease, become more sophisticated in the next year or > two. > > Any information would be very helpful. We're currently looking at > enhancing some security features in-house around Microsoft Office, and > want as much intelligence on the topic as possible. > > Thanks, > > Sebastian Muscarella Do not use any Microsoft "Windows" OS nor any Microsoft application which can be run on these OSes. oo--JS. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Assorted browser vulnerabilities
On Mon, 4 Jun 2007, Michal Zalewski wrote: > 1) Title: MSIE page update race condition >Impact : cookie stealing / setting, page hijacking, memory corruption >Demo : http://lcamtuf.coredump.cx/ierace/ Just FYI - my logs indicate that there is a fairly high percentage of patterns consistent with successful exploitation among Safari users (about 20%). For the non-vulnerable Firefox, this value is at 1% (for spoofed User-Agent strings, random pranks, etc). As such, the value for Safari seems significant, particularly since this PoC is timing-dependent and fine-tuned for MSIE. I have no immediate way to test it, but feel encouraged to explore this further. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Macro threats
When I do penetration tests I think macros are a useful tool. Most organizations now have strong perimeter defenses. So the initial foothold onto the network is a substantial challenge. For larger networks you can anticipate stupid (unknowning) users that will launch a macro. Everyone has their favorite set of excel macros after all. It's not a clever attack, but it gets the job done. The challenge of getting a foothold may increase the pressure to use macro attacks. However, overall I think there will be a slight decline In favor of not using macros is Web 2.0. Via web "defacement", XSS, DNS attacks, and social networking sites that I can fairly confidently find a secondary target that I know my primary target will visit. I can then attack IE/Firefox. I think it's a fair bet to say there's always an exploit for IE/Firefox/Flash/libjpeg/libpng/wmv/mpeg/etc that's standard content for web pages. Further, Office 2007 is now on the scene. While I have no expertise on Office software is generally more prone to bugs (and thus attacks) earlier in it's life cycle. Therefore, Office attacks might focus more on direct exploitation rather than using a macro. The above is just my opinion. I have no hard data supporting it one way or another, so take it as you will. -Matt On 6/5/07, Muscarella, Sebastian (IT) < [EMAIL PROTECTED]> wrote: Wanted to ask this forum's opinion on the state of macro threats. While we have not seen too many this past year which were actively exploited, we wanted to know if there are any indications on whether this threat would increase, decrease, become more sophisticated in the next year or two. Any information would be very helpful. We're currently looking at enhancing some security features in-house around Microsoft Office, and want as much intelligence on the topic as possible. Thanks, Sebastian Muscarella -- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Matthew Wollenweber [EMAIL PROTECTED] | [EMAIL PROTECTED] www.cyberwart.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Kevin Johnson BASE <= 1.3.6 authentication bypass
>I think your "vulnerability report" sucks (to use your word.)
>1) You use very unprofessional language
ghhh.
>2) You provide no links to either Base or the Base+ fork so the reader can
>check for themselves.
learn to read or to use google. (whats on the same top of my posting?)
>3) You provide no source from the Base+ fork to show how its
>authentication scheme is not vulnerable
it's open source. go - check it yourself.
>4) You personalize your report by using Kevin's name, in an attempt to
>embarrass him
it seems that you haven't yet noticed what is the name
of his *security* product ;-)
>5) You provide no evidence that you have ever contacted the Base project
>and notified them of your "discovery"
full disclosure.
>6) You don't even mention that an authentication vulnerability was
>**reported and fixed** more than a year ago, nor do you mention how your
>report relates to that vulnerability [1][2][3]
you haven't done your homework. this vulnerability has nothing
to do with those you discovered.
>7) You don't explain that the code you posted is not part of the
>authentication system and that the auth code is in base_auth_inc.php.
learn to read. lol.
>8) You don't explain what you mean by "what if not?" The answer is, if
>not, then authentication is required, you do have a role and you have
>already authenticated.
at this point you prove that you have no clue.
please, stfu and go offlist noob.
On 6/5/07, Paul Schmehl <[EMAIL PROTECTED]> wrote:
> --On June 4, 2007 10:35:40 PM +0300 Johnny Storm <[EMAIL PROTECTED]>
> wrote:
>
> > Basic Analysis and Security Engine (BASE)
> > (http://base.secureideas.net/)
> >
> >
> > One more security product with lame bugs...
> >
> > Let's look at Kevin's authentication code,
> > for example in base_main.php (all pages vulnerable):
> >
> > [...]
> > 64 // Check role out and redirect if needed -- Kevin
> > 65 $roleneeded = 1;
> > 66 $BUser = new BaseUser();
> > 67 //if (($Use_Auth_System == 1) && ($BUser->hasRole($roleneeded) ==
> > 0)) 68 if ($Use_Auth_System == 1)
> > 69 {
> > 70 if ($BUser->hasRole($roleneeded) == 0)
> > 71 {
> > 72 header("Location: $BASE_urlpath/index.php");
> > 73 }
> > 74 }
> > [...]
> >
> > Where is bug?
> > Yes, your browser will redirect after received location header,
> > but what if not? ;-)
> >
> > Test with curl. This is not first authentication issue in BASE,
> > putting at risk users which use BASE authentication feature.
> > Google shows up many installations protected by this feature.
> >
> > All BASE versions with authentication are vulnerable.
> > ACID is not vulnerable, since it doesn't has such feature.
> > BASE+ fork has fixed this issue year ago.
> >
> > Use your web server authentication or BASE+, which sucks less.
> >
> I think your "vulnerability report" sucks (to use your word.)
> 1) You use very unprofessional language
> 2) You provide no links to either Base or the Base+ fork so the reader can
> check for themselves.
> 3) You provide no source from the Base+ fork to show how its
> authentication scheme is not vulnerable
> 4) You personalize your report by using Kevin's name, in an attempt to
> embarrass him
> 5) You provide no evidence that you have ever contacted the Base project
> and notified them of your "discovery"
> 6) You don't even mention that an authentication vulnerability was
> **reported and fixed** more than a year ago, nor do you mention how your
> report relates to that vulnerability [1][2][3]
> 7) You don't explain that the code you posted is not part of the
> authentication system and that the auth code is in base_auth_inc.php.
> 8) You don't explain what you mean by "what if not?" The answer is, if
> not, then authentication is required, you do have a role and you have
> already authenticated.
>
> [1]
> [2]
> [3]
>
> Paul Schmehl ([EMAIL PROTECTED])
> Senior Information Security Analyst
> The University of Texas at Dallas
> http://www.utdallas.edu/ir/security/
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Macro threats
On Tue, 05 Jun 2007 11:37:53 EDT, "Muscarella, Sebastian (IT)" said: > Wanted to ask this forum's opinion on the state of macro threats. While > we have not seen too many this past year which were actively exploited, > we wanted to know if there are any indications on whether this threat > would increase, decrease, become more sophisticated in the next year or > two. This is entirely dependent on how good a job the industry does in getting rid of even lower-hanging fruit. It's not going to go on a major burn as "big threat" as long as users keep on "ooh shiny!" clicking and similar easy ways to get your code run on the target. Of course, this also depends at least somewhat on what your threat model looks like. What you're likely to see in targeted attacks specifically aimed at your organization will be vastly different from the "mass market" threats. Also, beware of internal threats - things like subtly tweaked Excel files (consider things like "column 94 equals sum of columns 34, 38, 41, and 48, plus 0.25%" - what happens if some disgruntled employee changes that to 0.27%?) Or forged backstabbing memos/documents, etc etc. I wouldn't worry about macro threats until you've got a handle on those issues pgpFQctT19jQf.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Macro threats
Wanted to ask this forum's opinion on the state of macro threats. While we have not seen too many this past year which were actively exploited, we wanted to know if there are any indications on whether this threat would increase, decrease, become more sophisticated in the next year or two. Any information would be very helpful. We're currently looking at enhancing some security features in-house around Microsoft Office, and want as much intelligence on the topic as possible. Thanks, Sebastian Muscarella NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] screen 4.0.3 local Authentication Bypass
-Original Message- Subject: Re: [Full-disclosure] screen 4.0.3 local Authentication Bypass > Verified on OpenBSD I'm not seeing a 'Getpass error' message on 4.1-STABLE current, but there does seem to be a problem with locking and reattaching: $ screen [space] $ echo "This is the locked screen" This is the locked screen [^A^X] Key: [asdf\r] Again: [asdf\r] Screen used by Paul . Password: [^C] $ [\r] $ screen -r $ echo "This is the locked screen" This is the locked screen $ exit [screen is terminating] $ uname -rmsv OpenBSD 4.1 GENERIC.MP#0 i386 PaulM ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [TOOL] untidy - XML Fuzzer
List, I'm glad to release the second beta version of untidy; untidy is general purpose XML Fuzzer. It takes a string representation of a XML as input and generates a set of modified, potentially invalid, XMLs based on the input. It's released under GPL v2 and written in python. Project main site: http://untidy.sourceforge.net/ Special thanks go to Dirk Loss for his help and bug reports. Cheers, -- Andres Riancho ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] screen 4.0.3 local Authentication Bypass
Hi, On 6/4/07, Christian Khark Lauf <[EMAIL PROTECTED]> wrote: > >> Screen asks for a Password to unlock the screen. > >> Just press ctrl+c and it displays "Getpass error". > >> 2 seconds later the screen is unlocked and you`ve access. > > I can't reproduce this on either Mac OS X (screen 4.00.03) or > > Debian (screen 4.00.02) ... > > So goes here. Debian Etch, Screen version 4.00.03 (FAU) 23-Oct-06. > But maybe it's because I have a password directive in my .screenrc > (You need to enter a password if you want to resume the session via > screen -r ) Before every list member tests this and writes a mail because of a configuration issue or a stupid patch introduces by OpenBSD, show us some code that proves the claim. Cheers Lolek ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] screen 4.0.3 local Authentication Bypass
+++ Oliver Starke [Tue, Jun 05, 2007 at 09:31:02AM CEST]: > > does not work on NetBSD 3.0 > uname -a > NetBSD xxx.yyy 3.0 NetBSD 3.0 (ZZZ) i386 Also not on FreeBSD 6.2-Stable, screen-4.0.3... Frank -- Freedom's just another word for nothing left to lose... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] screen 4.0.3 local Authentication Bypass
Hi, does not work on NetBSD 3.0 uname -a NetBSD xxx.yyy 3.0 NetBSD 3.0 (ZZZ) i386 Cheers OS On Mon, 4 Jun 2007 05:36:31 +0200 (CEST) [EMAIL PROTECTED] wrote: > Please take a look at the Attachement dear List moderator. :) > > Kind regards, > Rembrandt - ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
