Adobe Flash Temporary Filename Scheme Problem

Exploit Code :

# SecurityReason Note :
# References :
http://jbrownsec.blogspot.com/2010/03/adobe-flash-temporary-filename-scheme
.html

Today, I received this from Adobe PSIRT:

"We are targeting May for the next release of Flash Player, which would
include the fix for this issue. We will provide more information as we get
confirmation of the schedule and any other helpful details."

Going on 6 months and they still can't seem to check if mkstemp() returns
-1.

I don't view this much as a security issue, and you may or may not
depending on the factors you consider. I also know it costs money release
patches things, but really, they could have handled this a lot better. I'll
go into some detail now..

I was watching some flash video on Vimeo and then happened to ls my /tmp
directory. Catching my eye was a certain filename or two, with names such
as "Flash7f9Lk3" and "Flashm10PDtY". I soon figured out that when viewing
flash videos on Firefox with Adobe Flash Player 10 plug-in, as buffered, a
copy of the video is downloaded to /tmp with the first part of the filename
always being "Flash" and the last part being six random case-sensitive
alphanumeric characters.

a-z (26) + A-Z (26) + 0-9 (10) = 62

62 ^ 6 = 56,800,235,584

So there are ~56 billion different filenames that can be chosen in this
scheme. But, you don't need to create ~56 billion yourself, just a few
million should do the job.

We see here they use mkstemp() to create the temporary files.

The code looks something like this:

strcpy(filename,"/tmp/FlashXXXXXX");

i=mkstemp(filename);

if(i)
{
.....

Hmmm. They check if mkstemp() returns an open file descriptor, but what if
it returns -1?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d1f6d0 (LWP 27117)]
0xaafab279 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
(gdb) i r
eax 0x1e 30
ecx 0x76656c5f 1986358367
edx 0xaa80b000 -1434406912
ebx 0xab725210 -1418571248
esp 0xbf8f53e0 0xbf8f53e0
ebp 0xbf8f5408 0xbf8f5408
esi 0xcf79974 217553268
edi 0xcf79958 217553240
eip 0xaafab279 0xaafab279
eflags 0x10206 [ PF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x/i $eip
0xaafab279: mov (%ecx),%eax
(gdb) bt
#0 0xaafab279 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#1 0xaafab44d in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#2 0xab1990a0 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#3 0xab1a2ed5 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#4 0xab1104c0 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#5 0xab1a4f6e in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#6 0xaadb4565 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#7 0xaadb7cc3 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#8 0xb77cb3bd in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#9 0xb77cc6a0 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#10 0xb77cac57 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#11 0xb77d3004 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#12 0xb77cd1fd in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#13 0xb79514d1 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#14 0xb795130a in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#15 0xb7275367 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#16 0xb72800c9 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#17 0xb79856c8 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#18 0xb7955fea in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#19 0xb78d8eb6 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#20 0xb78c3db8 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#21 0xb6bc7dad in ?? () from /usr/lib/libglib-2.0.so.0
#22 0xb6b90b88 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#23 0xb6b940eb in ?? () from /usr/lib/libglib-2.0.so.0
#24 0xb6b94268 in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#25 0xb67c9634 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xaadbab17 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#27 0xb6b912b6 in ?? () from /usr/lib/libglib-2.0.so.0
#28 0xb6b90b88 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#29 0xb6b940eb in ?? () from /usr/lib/libglib-2.0.so.0
#30 0xb6b94268 in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#31 0xb78c39e4 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#32 0xb78d8b58 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#33 0xb78d8cef in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#34 0xb798566a in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#35 0xb7955f54 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#36 0xb78d8e38 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#37 0xb776d2b4 in ?? () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#38 0xb71caa8b in XRE_main () from /usr/lib/xulrunner-1.9.0.14/libxul.so
#39 0x080491ab in ?? ()
#40 0xb7d37775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#41 0x08048d11 in ?? ()
(gdb)

EEXIST anyone?

I contacted Adobe on 09/18/2009, exchanged a few emails, one of interest
being

"Resolving this issue requires some architectural changes that are not
appropriate for a security patch."

Even if its not much of a security issue, but an interesting programming
mistake, a local user can still crash anyone else's Firefox process that is
using the Adobe Flash plug-in.

And now Adobe PSIRT says they want more time...

Waiting 8 months for them to check the return value of mkstemp() is
unacceptable.

Proof of concept? That should be easy (hint: write your own scheme or try
looping mkstemp() =])

Security

IT News

Search

SecurityAlert Database

About SecurityAlert

ExploitAlert Database

SecurityReason Research

WLB Database

Send to WLB

About WLB

Security Audit

Schedule

Prices of services

Contact

SecurityReason IT News

SecurityAlert

World Laboratory of Bugtraq

ExploitAlert

Apache

PHP

Contact

About SecurityReason