Column security problems caused by crossdomain. xml security policy files

Column security problems caused by crossdomain. xml security policy files

This is a reflection on crossdomain. xml security policy files. It is neither a gimmick nor a bloody case !! I first realized that when I first came into contact with Flex a few years ago, I could solve the problem with ignorance. Now I have had to deal with countless problems. This is a pleasant sunshine afternoon, I happily wrote code, arranged the schedule, organized the documents, and planned to receive an email when I could go home for dinner today, A flash cross-domain security vulnerability deployed on an almost forgotten server requires urgent repair.

Wipe, what? Isn't that funny? What is Nima? What is this? The second Monk was confused about security vulnerabilities? So I did not deploy the Server policy file. I did not deploy it. I did not deploy the security policy file. When I came, I had it, come on, right ...... It's useless to say anything else. Now we have to solve the problem, so we can build a crossdomain. put the xml file under the server. No, no, just a few clicks on the keyboard and it will take 2 minutes to complete. This is a simple problem. hehahahahahahahahaha... when my brother thought that he could return to the email, he saw the word "wooyun Cross-Domain Vulnerability" and opened the yarn. It didn't matter. It scared me to death and I couldn't understand it at all, A variety of messy code segments and explanations are mostly anxious. Knowing that this is over, it is estimated that the time in the afternoon will be spent on this damn vulnerability ..

 

============================================= ==========

 

1. What is this vulnerability?

Through the analysis of the principle of CVE-2011-2461 and the case of careful study and learning, we can easily know that this vulnerability allows hackers to easily load SWF files on our server, disguised as sandbox files in our security domain, stealing users' privacy information. (Although nothing can steal live video streams? Okay, even if there is nothing to steal, it can be fixed !)

2. Why?

The reason is also analyzed in detail in this article because the security domain authorization adopts the "pilot loading" method, which is included in the API documentation officially provided by Adobe (for details, see import and load LoaderContext. securityDomain.

3. Is there such a vulnerability?

Yes, it does exist in SDK4.6, And the wooyun platform cannot be confused. Based on the sequence described in the article, the blogger carefully analyzed the sequence of swf process loading, checked each mentioned Code segment, loaded the principle, and finally added it to ModuleManager. in the as class, locate the following code segment in line L463.

Is the last content mentioned in this article.

4. How can I fix this vulnerability?

We don't have to worry about this. I have mentioned this in the article, and this vulnerability is still a historical vulnerability. The article provides four solutions:

 

For this vulnerability, the repair and defense measures may be as follows:

• Update development tools

• For swf files compiled using older versions of the SDK, you can use a new version of the development tool to recompile, or use a repair tool to install swf (https://helpx.adobe.com/flash-builder/kb/flex-security-issue-apsb11-25.html ). Of course, if the file is too old, simply delete it with brute force.

• Place swf and other static resource files with security risks under an independent domain name to avoid such problems to the maximum extent.

• When writing relevant code, developers should try to avoid using "pilot loading"; when using the Loader class, they should judge the legality of the loaded URL.

  We will pay attention to the tool mentioned. It is actually Adobe's explanation and repair of this vulnerability.

  5. Flex Security Issue APSB11-25 mentioned two solutions, a temporary emergency solution, a permanent solution once and for all, of course, we all know that this is definitely the second reliable type.

  Official vulnerability address, tool address, requires a computer to install the air Environment

  Emergency solution: Download the repair tool provided by the official website to fix the swf files with vulnerabilities, which is simple, fast, and feasible.

  Permanent solution: update the SDK version used by developers. This problem has been fixed by the SDK above 4.6 as described in the article, but the blogger also uses the SDK 4.6, but this problem really exists, think of the existence of the 4.13 SDK, So we replaced the SDK, re-compiled, released, and detected it with a vulnerability tool. The result shows that there are no vulnerabilities. View ModuleManager. the as class found that the code segment has changed as follows:

  We can also perform verification by parsing the mentioned command line into text, switch the command line to the FB installation path, and then go to sdks/bin, run swfdump-abc-path/xxx.swf> cmd.txt to convert the swf binary into the txt text format. Run the preceding command on the two swf files before and after the fix, then use the file comparison software Beyond compare (the blogger computer was installed a long time ago, useful software, and other comparison software). The results are as follows:

  The comparison result is only two different parts. The first part is the file name, which is named by the blogger. The second part is the figure above, that is to say, the comparison between the previous and subsequent operations can find that the ModuleManager is indeed modified. the code in as can solve the problem. Both the wooyun platform and the official website provide feasible solutions.

  6. What does Bo talk about?

  The blogger was so cool that I thought I could change the ModuleManager In SDK 4.6. is it possible for as? No. Even though I have manually modified the code, it completely deceives myself. I know that there are many changes, and FB doesn't know, the system needs to package and re-use ant to run it without compilation.

  7. What is the impact of the change?

  Choose Tool Repair, unless the code is not maintained in the future, this unsafe correction measures, in case that the unfortunate programmer forget the Tool Repair, will wait for approval. That is not to say that a later version of the SDK is desirable. a later version of the SDK requires support from a later version of the flash player Plug-in, which may affect user experience. You need to update your own plug-in for use, however, most users' computers use the new FP version, which is currently 17beta, while SDK4.13 only requires fp14.0 or later. Why is it not applicable to SDK4.7 or SDK4.6A? The bloggers think that these sdks also have vulnerabilities and don't want to waste time fixing them every day.

   

  I should add a few more images to my blog post, but I haven't eaten yet .. Let's just think about it. I really want to see a few of my concerns, and the two articles mentioned are quite detailed. I just introduced them here.