Category Archives: Security

LocalConnection Bug in Flash Player

So I’ve had this problem for ages, and couldn’t find anyone online writing about it.

LocalConnection in AS3 is used to send messages between Flash SWFs in a browser window. It’s also used as a hack to invoke garbage collection in the Flash Player.

I’ve been using it in some recently applications to ensure only one instance of a SWF is loaded at a time on a computer and to display a message to a user if a window with the application is already open.

It’s usually be pretty straight forward.

var LocalConn:LocalConnection = new LocalConnection();

Declares it

			try {
			} catch(error : ArgumentError) {
trace("Uh oh... Looks like it's already running");

Only one connection string can be used at a time, and if another SWF in the another browser window (or another tab… or another browser for that matter) tries to connect that ArgumentError will be thrown.

Unfortunately, there is a annoying bug where sometimes, even if no other instances are open, the LocalConnection thinks someone is still running on the same connection string…

I’ve experienced it happening when simply testing in Flash Builder and FDT… Sometimes I am working on another part of my application when one test the application says it’s already running… I’m confused at this point because I know nothing else is running…

I think I’ve narrowed down WHY it happens. It seems to happen when Flash is closed unexpectedly. For example, on Google Chrome, if you run the SWF and then for some reason Flash crashes (you know… the “uh oh Flash crashed” bar that appears at the top of Chrome), it seems that the LocalConnection is never officially closed.

What sucks is that you either have to change the connection string or reboot your computer (restarting browsers don’t work).

If anyone else has experienced this or knows any fixes, please let me know in the comments. I’ve been experiencing this problem since at least Flash Player 9. I’ve reported it on Adobe’s ticketing system… unfortunately they don’t allow anyone to read the ticket because they restricted viewing deeming it a possible “security” flaw – but maybe if other people are experiencing the issue they will put in a fix for it.

Update 5/10/2011
Qingyan Zhu from Adobe replied to my bug report:

Hi Danny,

Thanks for clarifying the issue.

But this is actually as designed.

So when there’s only one browser, if it crashes, then the segment gets reset, and the dangling LC endpoints get cleared.

But if there are two browser processes (depending, say on how IE is launched), or two processes that use LocalConnection (including any AIR app, Flash Projector, AIM, Y!IM, etc etc), then the corrupt memory segment will stick around.


Why you keep getting a computeSpectrum Security Error

Probably one of the worst and most frustrating bugs.

Turns out computeSpectrum will NOT work if ANOTHER Flash is using audio. Meaning if you have a Flash that using SoundMixer.computeSpectrum one of those super annoying security sandbox runtime errors will pop up on the browser if YouTube, GMail, or any other Flash using audio is opened.

The fix? There is no fix. No, security.allowDomain won’t work. No, placing crossdomain.xml all over your server won’t work either. The only thing one can do is catch the error (or use areSoundsInaccessible()) and have something else happen in between. This bug is especially annoying for game developers like me who are working on a game that uses the computeSpectrum to generate content…

Grrr… So annoying.

Encourage Adobe to fix this by voting for it.

T-Square Security Holes

At Georgia Tech, the course system that is used by students is called T-Square (based on Sakai). It’s pretty nice system that supports forums, wikis, chats, blogs, and a bunch of other tools.

Sakai is open source; consequently, Georgia Tech can maintain the software and fix and bugs it finds.

Unfortunately, I found security holes with T-Square. These holes can allow a hacker to access another users’ identity. If that user is a teacher or TA, the hacker can easily take their identity and edit grades. In fact, due to the poorly organized structure of Georgia Tech’s backend, the hacker can not only access the user’s T-Square account, but also their Oscar account (which holds even more private information, such as social security numbers).

I would love to share how to exploit this security hole;  unfortunately, my moral compass forbids me to publish my video of an example T-Square attack… yet. I’ve contacted Georgia Tech and hopefully they will patch it up. After they do to my satisfaction… then maybe I’ll post it on YouTube.

Now I’m not making this post to brag. I’m making a point. A high-esteemed technical university such as Georgia Tech should be able to find these problems with their system. Web developers should be educated on the basics of computer security so that their student’s private records are not compromised.

Really Quick Tutorial on One Way Encryption

It’s difficult for beginning programmers to grasp the idea of one way encryption. “How can I make an encryption that is impossible to reverse? Even if I know the algorithm to encrypt? And why would I ever want to do this?”

First let’s review a very basic two way encryption algorithm.

Take a string of text Danny.

A basic algorithm could be to push each of the letters to the right once.

Raw = Danny

Encrypt(“Dan”) = yDann

Obviously, this is a pretty poor encryption algorithm. A simple way of improving the encryption and making the output more scrambled is to encrypt the raw text twice.

Raw = Danny

Encrypt(Encrypt(“Dan”)) = nyDan

Still fairly poor, but it’ll suite for this example. Our Decrypt function would simply push the letters to the left.

Decrypt(“yDann) = Danny


Decrypt(Decrypt(“nyDan“)) = Danny

Before I now explain one way encryption, let me pose an example where one way encryption would be needed. has a database of millions of users. Each user has a username and a password stored in Google’s database. Any database administrator can view this data, including the passwords. So one way to protect user’s privacy is to encrypt the passwords before placing them into the database. Then, when a user logs into with their username or password, the password is encrypted using the same algorithm and then checked to see if it matches the password in the database. Makes sense right? If my password to google was Danny, the database could store yDann instead. Then, when I log on to and type in Danny in the password field, encrypts the password using the same algorithm mentioned above and compares it to yDann in the database. Since they are equal I’m able to log in! Hurray!

But there’s a huge problem! What if the database administrator to google discovered the algorithm written above? The database admin could just copy the password to my account and then go home and decrypt it! Then the admin would be able to log into my account and access my information!

This is where hashing, a form of one way encryption, comes into play.

Let’s go back to my password: Danny

Let’s try another algorithm, let’s change each letter to the number that corresponds with the letter.

A = 1
B = 2
C = 3
D = 4
E = 5
F = 6
G = 7
H = 8
I = 9
J = 10
K = 11
L = 12
M = 13
N = 14

So, Encrypt(“ABC“) =  123 // 1,2,3

Seems simple right? But this algorithm, as unsecure as it may be, is an example of a one way encryption algorithm!

Encrypt(“LC“) = 123 // 12, 3

ABC and LC have the same output! Meaning that it’s impossible to know, given the encrypted/hashed string 123, what the text was before the hashing algorithm took place.

So in the database of google under my username’s password could be 4114

Encrypt(“Danny“) = 4114 // 4, 1, 14

But when the evil database administrator sees my password of 4114, he (or she) won’t know whether my password is Danny, Dan, or DKD! Even if the algorithm is known, there’s no way to know for sure the value of the pre-hashed text. With longer passwords there’s even more possible combinations for each text.

Many computer scientists have spent their careers working on improving hashing algorithms. MD5 and SHA-1 seem to be the most popular hashing algorithms on the web (md5 is built into PHP); however, you should be careful not to just use these algorithms due to reverse hash lookups around the web.