5360874 2000-08-14 18:57 /130 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12206>
Ärende: MacroMedia Flash/Shockwave plug-in on linux : memcpy overrun
------------------------------------------------------------
problem.
From: Chiaki Ishikawa <Chiaki.Ishikawa@PERSONAL-MEDIA.CO.JP>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200008140726.QAA17112@sparc18.personal-media.co.jp>
X-PMC-CI-e-mail-id: 13428
A replacement library for checking well-known type of stack overrun
caused by memory copy / string copy operations has been made
available, namely libsafe.
I have used it on Linux and I spotted a couple of suspicous popular
programs on linux.
I have been using libsafe on linux and found that
- netscape plug-in for Flash/Shockwave plug-in seems to have
memcpy overrun problem.
( and adobe acrobat reader on linux have some issues with libsafe.
But this seems to be caused by the different libc, somewhat old
compat-libc, used by acrobat reader. So I won't go into details on
acrobat reader.)
Flash / ShockWave plug-in for netscape.
For netscape flash/shockwave plug-in on linux,
the log output below shows the output from libsafe.
The first and the second last messages are from the test
suite of libsafe.
The other logs are from netscape
(during flash/shockwave plug-in operation from what I remember).
You can see that the version of netscape 4.72, 4.73 and 4.74 suffered
from the memcpy() overwrite problem.
(During the period, the kernel was upgraded from 2.2.14
to 2.2.15,2.2.16, 2.4.0-test4, etc..)
ishikawa@standard$ more libsafe-netscape-showckwave-flash.bug Apr 23
01:04:15 standard libsafe.so[1534]: version 1.3 Apr 23 01:04:15
standard libsafe.so[1534]: detected an attempt to write across stack
boundary. Apr 23 01:04:15 standard libsafe.so[1534]: terminating
/opt2/tools/libsafe/exploits/t1 Apr 23 01:04:15 standard
libsafe.so[1534]: overflow caused by strcpy() Apr 29 04:35:23
standard libsafe.so[648]: version 1.3 Apr 29 04:35:23 standard
libsafe.so[648]: detected an attempt to write across stack boundary.
Apr 29 04:35:23 standard libsafe.so[648]: terminating
/opt/ns472/netscape Apr 29 04:35:23 standard libsafe.so[648]:
overflow caused by memcpy() May 2 02:11:53 standard
libsafe.so[1153]: version 1.3 May 2 02:11:53 standard
libsafe.so[1153]: detected an attempt to write across stack boundary.
May 2 02:11:53 standard libsafe.so[1153]: terminating
/opt/ns472/netscape May 2 02:11:53 standard libsafe.so[1153]:
overflow caused by memcpy() Jul 2 02:58:32 standard
libsafe.so[1648]: version 1.3 Jul 2 02:58:32 standard
libsafe.so[1648]: detected an attempt to write across stack boundary.
Jul 2 02:58:32 standard libsafe.so[1648]: terminating
/opt/ns473/netscape Jul 2 02:58:32 standard libsafe.so[1648]:
overflow caused by memcpy() Jul 2 23:39:05 standard libsafe.so[639]:
version 1.3 Jul 2 23:39:05 standard libsafe.so[639]: detected an
attempt to write across stack boundary. Jul 2 23:39:05 standard
libsafe.so[639]: terminating /opt/ns473/netscape Jul 2 23:39:05
standard libsafe.so[639]: overflow caused by memcpy() Jul 8 03:04:47
standard libsafe.so[390]: version 1.3 Jul 8 03:04:47 standard
libsafe.so[390]: detected an attempt to write across stack boundary.
Jul 8 03:04:47 standard libsafe.so[390]: terminating
/opt/ns473/netscape Jul 8 03:04:47 standard libsafe.so[390]:
overflow caused by memcpy() Jul 11 04:10:47 standard
libsafe.so[1424]: version 1.3 Jul 11 04:10:47 standard
libsafe.so[1424]: detected an attempt to write across stack boundary.
Jul 11 04:10:47 standard libsafe.so[1424]: terminating
/opt2/tools/libsafe/exploits/t1 Jul 11 04:10:47 standard
libsafe.so[1424]: overflow caused by strcpy() Aug 14 00:30:11
standard libsafe.so[393]: version 1.3 Aug 14 00:30:11 standard
libsafe.so[393]: detected an attempt to write across stack boundary.
Aug 14 00:30:11 standard libsafe.so[393]: terminating
/opt/ns474/netscape Aug 14 00:30:11 standard libsafe.so[393]:
overflow caused by memcpy()
It has been rather difficult to figure out what URL exactly caused
the libsafe to detect the error and abort netscape.
Often times, when I clicked on a new URL, one of the URL links in
the new web page is a flash shockwave page and the loading
automatically started, and before I knew it, the netscape aborted.
But for the last one, dated Aug 14, I know what URL caused the abort
exactly. This prompted me to write this article. (Presumably, those
who have access to the source code of the Flash/Shockwave plug-in
should be able to fix this problem easily by trying the URL.)
URL:
http://www.washingtonpost.com/wp-srv/photo/conventions/
There is a big photo of the national political convention
in the middle and "ENTER" button.
Clicking on "ENTER" will start loading the flash/shockwave
movie or something and this triggered the error reported
in the above log. (As soon as the loading of ~ 500KB
data endded, my netscape aborted.)
Severity/Exploit:
I have no idea how hard it is to exploit this memcpy overrun.
But given that some linux distribution vendors felt it was necessary
to do something about jpeg decoder bug in netscape, this plug-in issue
probably ought to be dealt with in a similar manner : this can cause
DoS attack certainly.
Before I forget, let me explain that I tried to reach the people
responsible for technical problems/security problems at Macromedia
without success so far. Simply stated, I could not find contact
e-mail addresses easily. I am not a registered user of these programs
(they are available for free), and so it is very difficult to use
MacroMedia web submission forms. It has been a few weeks since I
wrote to various addresses I found on the web pages. I have not heard
from human recipients yet and decided to post this article instead in
the hope of getting someone at MacroMedia to become aware of the
problem.
(Come to think of it, I thought this may be marginally related to the
netscape browser itself, and so sent a message using the security
reporting form on the Netscape web page. I wonder if the message was
forwarded to MacroMedia.)
I would welcome anyone forward this post to responsible parties.
My suggestions to software vendors: on the web page,
either post a security-related contact address or at least a
generic e-mail address where these findings can be sent.
Posting only e-mail addresses for very limited use is not very helpful
under these circumstances.
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
(5360874) ------------------------------------------(Ombruten)
5388845 2000-08-22 20:32 /132 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12347>
Ärende: Re: FW: MacroMedia Flash/Shockwave plug-in on linux : memcpy
------------------------------------------------------------
overrun problem.
From: Chiaki Ishikawa <Chiaki.Ishikawa@PERSONAL-MEDIA.CO.JP>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200008221133.UAA07357@sparc18.personal-media.co.jp>
X-PMC-CI-e-mail-id: 13464
(I am "Bcc:"ing this to a few people who sent me
inquiries and suggestions.)
Here is a follow up to my own post several days ago.
Firstly, it turns out that macromedia does have a means of
bug reproting and discussion among the developers.
>Technical Issues and Reporting Bugs
>-----------------------------------
>The Webplayers Discussion Group provides an open forum to discuss
>technical issues regarding Macromedia Players. Also of interest are
>the Flash, Flash Site Design, and Generator
>DiscussionGroups. Macromedia Technical Support actively monitors these
>groups, as well as hosting a community of users there. Descriptions
>and links to these discussion groups can be found at:
>
>http://www.macromedia.com/support/newsgroups.html
>
>Bug reports may be sent to beta_flashlinux@macromedia.com To allow us
>to investigate reported bugs, please include the following
>information:
>
>1) Platform and version
>2) Netscape version
>3) Reproducible steps including a URL to the web site where the
> problem was encountered.
>If we need further information about a bug, you will be contacted. An
>automated reply will be sent to assure you that we have received your
>bug report. Due to the volume of mail received we are not able to
>individually respond to each report.
Now, more details and the result of experiment suggested by Solar
Designer.
Before proceeding, I would like to thank Sharif Nassar who pointed out
that I should be able to know the exact URL by using web proxy such
as squid or junkbuster when I access the problematic web pages. By
using this method (which was indeed already set up on my PC, and I had
forgotten about the existence), I could find a couple of URLs that
contains flash/shockwave contents.
The slightly edited (to fit on narrow screen) raw squid log :
966180611.524 98883 127.0.0.1 TCP_MISS/200 526846 GET
http://www.washingtonpost.com/wp-srv/photo/conventions/flash/conv_intro/intro.swf
- TIMEOUT_DIRECT/www.washingtonpost.com application/x-shockwave-flash
966276649.312 4874 127.0.0.1 TCP_MISS/200 5870 GET
http://www.csmonitor.com/graphics/promos/dempromo.swf -
TIMEOUT_DIRECT/www.csmonitor.com application/x-shockwave-flash
The first one is the one that I mentioned at Washington Post site.
I didn't know I had accessed the second flash/shockwave page before.
Let us call the URLs as [1] and [2] respectively.
( URL [1] at Washington post., URL [2] at Christian Science Monitor.)
Solar Designer:
>libsafe depends on all components of programs you use to be compiled
>with frame pointers. If gcc's -fomit-frame-pointer was used on at
>least one source file in at least one software component (such as a
>browser plug-in), then libsafe's checks do the wrong thing and you
>may in fact be introducing DoS possibilities by using libsafe.
I should have known this.
>Have you tried visiting this URL without libsafe installed? If it
>still causes a crash, then you really have something to report.
Now, as suggested by Solar designer, I did the experiment.
I removed the loading of libsafe before running netscape/flash plug-in
to access the above URLs and compared result.
Result.
============================================================
No libsafe. With libsafe.
------------------------------------------------------------
Access to URL [1] Seems to be OK. Aborted by libsafe.
URL [2] OK. OK.
============================================================
The URL [2] seems to contain much smaller flash data and
netscape/flash plug-in had no problem with/without libsafe in
handling it. A little strange but such is life. I would appreciate
any true/false confirmation from people using linux for x86.
The URL [1] caused the abort by libsafe as reported previously,
but when I removed libsafe from the dynamic library loading path,
netscape/flash plug-in seems to handle it without problem.
(Since the data is large, I only looked at the first part of URL [1].
After a minute or so of initial dynamic images,
the screen comes to a menu selection and pauses.
I could pick up the menu all right. I didn't investigate further.
With libsafe, netscape gets aborted before showing ANY images at all
after downloading ~500kb data .)
So as Solar Designer suggested there may be issues concerning the
compilation switches (especially the one that controls the
preservation of frame pointer) of netscape flash/shockwave plug-in
and libsafe. What puzzles me is that URL [2] doesn't cause abort by
libsafe. But again, someone in the know can figure out if the
problem with URL [1] is genuine or libsafe artifact.
(OK, now I understand that IF one module of NETSCAPE is compiled
without frame pointer preservation, then such might cause the abort of
libsafe at a seemingly unrelated module. Right?
But in this particular case, I think it is the plug-in module for
flash/shockwave since I only see this abort when flash/shockwave page
is accessed.)
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
(5388845) ------------------------------------------(Ombruten)