The 3.4 version of Flex SDK is available. An important vulnerability has been identified in Flex 3.3 SDK and earlier versions which could result in cross-site scripting. This technote explains the important vulnerability found in the previous version of the Flex SDK.

Please go to Adobe Open Source website and download the Flex 3.4 SDK version.

It seems that Flex 4 SDK is not affected by this vulnerability because it uses SWFObject templates.

Resources:
http://www.adobe.com/support/security/bulletins/apsb09-13.html
http://kb2.adobe.com/cps/495/cpsid_49530.html
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3

Last end of the week has been a busy time for Adobe. They released quite a few updates to Flash and AIR platforms and some security updates for Flash Player, Acrobat Reader and Acrobat.

Now the last public version of Flash Player is 10.0.32.18 and can be downloaded from http://get.adobe.com/flashplayer/. The update refers to this security bulletin (APSB09-10).

Regarding AIR the update is more about bug fixing and changes to API. Find more reading Release notes for Adobe AIR developers on Adobe. The new 1.5.2 version of AIR can be downloaded from http://get.adobe.com/air/.

Bellow are some related links where you can find more…

http://blogs.adobe.com/air/2009/07/adobe_air_152_now_available.html
http://www.adobe.com/support/documentation/en/air/1_5_2/releasenotes_developers.html
http://blogs.adobe.com/psirt/2009/07/update_to_apsb09-10_security_b.html
http://www.adobe.com/devnet/flashplayer/articles/flash_player10.0.32_security_update.html
http://get.adobe.com/flashplayer/
http://get.adobe.com/air/
http://www.adobe.com/support/security/bulletins/apsb09-10.html

Today I managed to find this error twice. It is happening in AIR applications. I had the same application in Flex and then I ported it to AIR. The error that appeared is this:

SecurityError: Error #3015: Loader.loadBytes() is not permitted to load content with executable code.

The error is saying that you’re no more allowed to load executable byte arrays.

To resolve it just use allowLoadBytesCodeExecution property of LoaderContext class like this:

var myLoaderContext:LoaderContext = new LoaderContext();
myLoaderContext.allowLoadBytesCodeExecution = true;
 
var mySwfLoader:SWFLoader = new SWFLoader();
mySwfLoader.loaderContext = loaderContext;
mySwfLoader.addEventListener(Event.COMPLETE, handleLoadComplete);
mySwfLoader.addEventListener(HTTPStatusEvent.HTTP_STATUS, handleLoadFault);
mySwfLoader.load(myByteArray);

This is all. Hope this helps you.

Table of contents

1. Adobe Flash zero-day exploit in the wild
2. 0 Day Expoit in Flash Player.. Not so real

In a previous article in this series I told you about a reported exploit for Adobe Flash Player. It seems that the security bulletin that this exploit was based upon was released before the version 9.0.124.0 of the Player. Reading the latest security bulletin Adobe informs us that the exploit is not applicable to this version of the player:

This is not a zero-day exploit. Despite various reports that have been circulating, the Flash Player Standalone 9.0.124.0 and Linux Player 9.0.124.0 are NOT vulnerable to the exploits discussed in conjunction with the previously disclosed vulnerability Symantec posted on 5/27/08. Symantec originally believed this to be a zero-day, unpatched vulnerability, but as their latest update on their Threatcon page indicates, they have now confirmed this issue does not affect any versions of Flash Player 9.0.124.0.

So our recommendation is to update your Flash player to the latest version in order to prevent the nastiness that may occur with this exploit.

Table of contents

1. Adobe Flash zero-day exploit in the wild
2. 0 Day Expoit in Flash Player.. Not so real

A very recent news on Zdnet announced that there is an very serious exploit that Adobe Flash Players 9.0.115.0 and 9.0.124.0 are vulnerable; other versions may also be affected.

The link to the whole story is here.

In this post we will implement a login process with remember password functionality. In AS3 and also in AS2 we can use a SharedObject to store data on the users browser. Shared objects are similar to the all known browser cookies but are managed by the flash player. Shared objects can store data also remotely on the server and using this feature some complex communication models can be implemented. But we will focus on our login with remember password (see here the working application).

For this we need a server-side and I used PHP because my preferred server-side language is PHP. The server-side is very simple and contains one function that will check the user name and the password with some hard coded constants. Here is the code inside login.php:

// hard coded username and password
define("USER","flexer");
define("PASS","fx{r}");
// login function
function login($u,$p) {
    // checking for valid username and password
    if (strlen($u)>0 && strlen($p)>0 && $u == USER && $p == PASS) {
        // login was successful
        $loginOk = 1;
        $loginErr = "";
    } else {
        // login failed
        $loginOk = 0;
        $loginErr = "Invalid user and/or password!";
    }
    // returning an XML with data
    return "<login><loginOk>".$loginOk."</loginOk><loginErr>".$loginErr."</loginErr></login>";
}
// we send the xml header
header("Content-type: text/xml");
// we print resutl to output
echo login($_REQUEST["username"],$_REQUEST["password"]);

What this server-side script file does can be easily understand from the comments so we will move forward to client-side.

For the remember password functionality we use a SharedObject which will be saved in the local machine. This file can be encoded (we didn’t encode it) and a location to save in can be specified. More about encoding here and about setting a location here.

A SharedObject is called like this

var _remeberSO:SharedObject = SharedObject.getLocal("loginData");

and what it happens:

• if the shared object named “loginData” doesn’t exists a new one with empty data property is created
• if the shared object named “loginData” exists the previously saved info is retrieved and the data property is filled in with that info

The data property is set like this:

_remeberSO.data.username = username.text;
_remeberSO.data.password = password.text;

and is get in the same manner.

To save/write the object we use

_remeberSO.flush();

To clear

_remeberSO.clear();

In this example we use also a ViewStack but to make everything more clear bellow you can study the whole flex code and I hope you’ll understand very well what is happening from the comments.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
    layout="absolute" width="253" height="307" 
    creationComplete="init()">
    <mx:HTTPService id="doLoginService" method="POST" 
        url="http://www.flexer.info/wp-content/uploads/2008/05/login.php" 
        resultFormat="e4x" result="handleDoLoginResult(event)" 
        showBusyCursor="true"/>
    <mx:ViewStack x="10" y="10" width="233" height="287" id="myStack" 
        change="handleStackChange(event)">
        <mx:Canvas id="logIn" width="100%" height="284">
            <mx:Label x="0" y="77" text="Username:"/>
            <mx:Label x="0" y="103" text="Password:"/>
            <mx:TextInput x="75" y="75" id="username" width="158"/>
            <mx:TextInput x="75" y="101" id="password" width="158" 
                displayAsPassword="true"/>
            <mx:CheckBox x="75" y="131" label="Remeber password" 
                id="rememberStack1"/>
            <mx:Button x="75" y="157" label="Login" 
                click="handleDoLoginClick(event)"/>
            <mx:Text x="0" y="0" width="233" height="67">
                <mx:htmlText>		
<![CDATA[Use the following login data.
 
Username: <b>flexer</b>
Password: <b>fx{r}</b>]]>
                </mx:htmlText>		
            </mx:Text>
        </mx:Canvas>
        <mx:Canvas id="loggedIn" width="100%" height="285">
            <mx:Text x="0" y="0" width="233" height="219">
                <mx:htmlText>
<![CDATA[<b>You are logged in!</b> You can log out 
and specify if you prefer to have the 
password remembered next time. 
 
To see that the username and password 
are remembered please use the follwing
scenarios:
 
1) Refresh the whole browser page.
2) Logout and the refresh the whole 
page. 						
3) Uncheck "Remember password" and
refresh the page.
4) Uncheck "Remember password",
logout and refresh.]]>
                </mx:htmlText>
            </mx:Text>			
            <mx:CheckBox x="0" y="227" label="Remember password" 
                id="rememberStack2"/>
            <mx:Button x="0" y="253" label="Logout" 
                click="handleLogout(event)"/>
        </mx:Canvas>
    </mx:ViewStack>
    <mx:Script>
        <![CDATA[
            import mx.controls.Alert;
            import mx.rpc.events.ResultEvent;
 
            // our shared object that will save
            // the username and password localy 
            private var _remeberSO:SharedObject;
 
            // initialization
            private function init():void
            {
                // getting data from shared object
                // if the object named "loginData" and
                // saved localy doesn't exists it is 
                // created without data
                // if it exists the data is recovered and
                // put inside "data" property
                _remeberSO = SharedObject.getLocal("loginData");
                // if we have username and password saved
                // we do auto-login
                if (_remeberSO.data.username != undefined && 
                    _remeberSO.data.password != undefined)
                {
                    rememberStack1.selected = true;
                    username.text = _remeberSO.data.username;
                    password.text = _remeberSO.data.password;
                    // calling the login service to check 
                    // the username and password
                    doLoginService.send(_remeberSO.data);
                }
            }
 
            // called when the "Login" button is clicked
            private function handleDoLoginClick(event:MouseEvent):void
            {
                var sendData:Object = { username:username.text,
                                        password:password.text };
                // calling the login service
                doLoginService.send(sendData);
            }
 
            // called by the "HTTP Service" when successful
            private function handleDoLoginResult(event:ResultEvent):void
            {
                // get the status of login process
                // loginOk = 0 - means invalid username/password
                // loginOk = 1 - means login successful
                // loginErr = "" - when loginOk = 1
                // loginErr = "error" - when loginOk = 0
                var loginOk:uint = int(event.result.loginOk);
                var loginErr:String = event.result.loginErr.toString();
                if (!loginOk) {
                    // if the login failed we alert
                    Alert.show(loginErr);
                } else {
                    if (rememberStack1.selected) {
                        // if we selected remember password
                        // we save the login data in the shared object
                        _remeberSO.data.username = username.text;
                        _remeberSO.data.password = password.text;
                        // saving/writing
                        _remeberSO.flush();
                    } else {
                        // otherwise we clear the shared object
                        _remeberSO.clear();
                    }
                    // move to next stack
                    myStack.selectedIndex++;
                }
            }
 
            // called when the "Logout" button is clicked
            private function handleLogout(event:MouseEvent):void
            {
                if (!rememberStack2.selected) {
                    // if have NOT selected remember password
                    // we clear the shared object
                    _remeberSO.clear();
                } else {
                    // if we selected remember password
                    // we save data as we may login 
                    // without checking the checkbox in the
                    // first screen but we want to select it
                    // after login
                    _remeberSO.data.username = username.text;
                    _remeberSO.data.password = password.text;
                    // saving/writing
                    _remeberSO.flush();
                }
                myStack.selectedIndex--;
            }
 
            private function handleStackChange(event:Event):void
            {
                // we are sychronizing the two checkboxes
                if (myStack.selectedChild == logIn)
                {
                    // we got back to first screen - login
                    rememberStack1.selected = rememberStack2.selected;
                } else {
                    // we got to the second screen
                    rememberStack2.selected = rememberStack1.selected;
                }
            }
        ]]>
    </mx:Script>
</mx:Application>

The working application is bellow and you can try the following scenarios to test the login process:

1. Refresh the whole browser page
2. Logout and the refresh the whole page
3. Uncheck “Remember password” and refresh the page
4. Uncheck “Remember password”, logout and refresh

Here is the documentation about shared objects very nice and clean (by Adobe, on Livedocs).

The paper “Application-Specific Attacks: Leveraging the ActionScript Virtual Machine” written by Mark Dowd in which he describes various techniques that promise to open up a class of exploits and vulnerability research previously thought to be prohibitively difficult. While the Flash vulnerability described in the paper [pdf] has been patched by Adobe, the presentation of a reliable exploit for NULL pointer dereferencing has the researchers who have read the paper fascinated. Thomas Ptacek has an explanation of Dowd’s work, and Nathan McFeters at ZDNet is ‘stunned by the technical details‘

Adobe plans to release a new security update for the Flash Player on 9 April 2008. The update plans to fix the issues listed in the December 2007 Security Bulletin ABSP07-20 for DNS rebinding and cross-domain policy file vulnerabilities, and Security Advisory APSA07-06 for cross-site scripting vulnerabilities in SWFs.

Some of the notable changes:

1. the socket xml file introduced by the 9,0,115,0 is now mandatory
2. HTTP policy files will no longer permit socket access

These changes come from the need of better DNS hardening, to ensure that ActionScript cannot be used as a means for a DNS rebinding attack (as referenced in Security Bulletin ABSP07-20) that could result in an unauthorized socket connection.

The whole bulletin with all the updates is located here.

Table of contents

1. How to make your applications smaller and reduce the loading time?
2. How to create a swf RSL from a swc and how to use it
3. How to reduce the size of any flex app using RSL
4. RSL further details

In a previous article I told you about the benefits of RSL’s. But you need also to know how to create them from a swc and how to use them.

First step is to create a new “Flex Library Project”. Write all the code you want to have in it. Then in your main application (or module or where you want to use the library you created) add a reference to that swc. Use the option “Merged into code” for the first stages of development.

Once you are happy with your library (works ok, no more code needs to go in) you need to change how you reference your swc, you need to change the link type to “Runtime shared library (RSL)”.

But RSL will only work (as far as I know it) with swf and you have a swc. So you need to pack your swc as a swf. Here is how to do it:

mxmlc.exe -o=myRSLmodule.swf -file-specs=<an as file form your swc> -source-path=<source path>

an example from one of my modules:


"c:\Program Files\Adobe\Flex Builder 2\Flex SDK 2\bin\mxmlc.exe" -o=d:\work\Flex\qUtils\bin\qUtils.swf -file-specs=d:\work\Flex\qUtils\src\com\qbic\desktop\desktop.as -source-path=d:\work\Flex\qUtils\src

Now you will have 2 files the swc and the swf.

All you have to do is to edit the old reference to the swc:

1. go to project properties
2. flex build path
3. library path
4. extend the node that shows your initial reference
5. double click on Link type
6. change the link type to “Resource shared library (RSL)”
7. enter the URL to your swf(yes you need to upload the swf and the swc before you get to this point )
8. Un-check the “Auto extract swf to RSL URL” option
9. Click on Source Attachement (not double-click)
10. click on the remove button

That is it! You now have an RSL included in the project.

Advantages of using RSL:

1. Code reuse
2. swf that contains the RSL code will be cached by the web-server and by the client browser
3. Smaller download size if the application uses several modules that will need some common code (the RSL code)
4. Faster download

Dis-advantages:

1. Because of the local or network sandbox in flex you will not be able to start your application from local filesystem. You will need to deploy the application
2. If you deploy the application keep in mind the security sandbox that can prevent cross-domain scripting (application hosted to a domain and the RSL to another). You can use the crossdomain.xml file to resolve this problem.
3. This method is unsupported by ADOBE. It is in fact a hack. The Adobe team is working on improving support for RSL’s in Flex Builder 3.
4. If you will host your application on a different server (even on the same server can have this problem) you are open to a man in the middle type attack. Or if someone will hack that server and replace the swf with his own.

Even if there seems less advantages for using this the bandwidth you saved with this method and the smaller loading time of the application will make you choose this approach.

Last word: Once you have finished working on a module or the application I suggest you compile it using the “no debug” option in order to further reduce the size (and also increase the performance) of your application. And yes you can use a RSL build with “no debug” in an application that is compiled with debug turned on (development phase)

compc -debug=false ...


Today I found this interesting library – AS3 Crypto Framework 1.3. Many algorithms used for cryptography are implemented in this class: TLS 1.0 support (partial), X.509 Certificate parsing and validation, RSA (encrypt/decrypt, sign/verify), AES, DES, 3DES, BlowFish, XTEA, RC4, ECB, CBC, CFB, CFB8, OFB, CTR, MD2, MD5, SHA-1, SHA-224, SHA-256, PKCS#5, PKCS#1 type 1 and 2, HMAC, Random, TLS-PRF, some ASN-1/DER parsing and more.

Demo for the class is found at http://crypto.hurlant.com/demo/, sources at http://crypto.hurlant.com/demo/srcview/, archive for download here (http://crypto.hurlant.com/demo/srcview/Crypto.zip) and the SWC can be downloaded from http://crypto.hurlant.com/demo/as3crypto.swc.