0day.today - Biggest Exploit Database in the World.
Things you should know about 0day.today:
Administration of this site uses the official contacts. Beware of impostors!
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!
Please, beware of scammers!
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Adobe Flash - textfield Constructor Type Confusion
Author
Risk
[
Security Risk Medium
]0day-ID
Category
Date add
CVE
Platform
Source: https://code.google.com/p/google-security-research/issues/detail?id=701 There is a type confusion vulnerability in the TextField constructor in AS3. When a TextField is constructed, a generic backing object is created and reused when subsequent TextField objects are created. However, if an object with the same ID has already been created in the SWF, it can be of the wrong type. The constructor contains a check for this situation, though, and throws an exception and sets a flag to shut down the player if this occurs. The backing object is then set to be of type TextField to avoid any modifications that have been made on it by the constructor from causing problems if it is used as an object of its original type elsewhere in the player. However, if the exception thrown by the constructor is caught, the exception handler can create another TextField object, and since the type of the generic backing object has been changed, an object of the wrong type is now backing the TextField, which makes it possible to set the pointers in the object to integer values selected by the attacker. The PoC swf for this issue needs to be created by hand. The original swf code is: try{ var t = new TextField(); } catch(e:Error){ var t2 = new TextField(); t2.gridFitType; } Then in the swf, a backing object of a different type with ID 0xfff9 is created, which causes the first constructor call to fail, and the second to cause type confusion. Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39461.zip # 0day.today [2024-12-25] #