Hot answers tagged flash
10
It's not called Flash Drive By, but Drive-By Download, and yes, it's basically downloading malware just by visiting an infected website. Usually drive-by downloads work by exploiting a browser vulnerability (or a vulnerability in plugin like Flash or Adobe Reader), which leads to remote code execution triggering the download of malware.
Unfortunately ...
6
No virus is possible if the browser has no bug.
No escalation to admin rights is possible if the OS has no bugs.
Unfortunately, bugs happen... in both the OS and the browser. Vulnerabilities which allow a non-admin process to gain admin rights (e.g. this one) are rather common, and it is usually assumed that getting through the browser is the complex part, ...
5
The answer is: yes. You should always worry about software.
"Complexity is the worst enemy of
secuirty"
--Bruce Schnieir
That being said, if your machine is fully patched one of the many flash 0-days will still compromise the machine. XSS is exploitable regardless if your machine patched. This flaw is usually exploited with JavaScript ...
4
While the "watching a screen" aspect of that site is pure flash, the screen sharing component is not. When you attempt to share your screen, it downloads an executable to install; an .exe on Windows, and a .pkg on Mac.
So, yes - it's a foreign binary with the capability to steal all of the data you mentioned and more; but the sharing isn't using flash, so ...
4
Targeting sandboxed platforms like Flash and Java will be excessively difficult if you're just starting out, so I suggest you learn to walk before you try to run.
Some stuff you'll want to know:
How to code in a low level language like C.
What the stack, registers, heap, etc. do, and what happens when you overflow them in various ways.
At least basic x86 ...
4
You are right. There are really many ways for a website to store persistent data on you, even if you dont want them too. Evercookie by Samy Kamkar is an example of this.
Quotede from the site of Evercookie it stores persistent data on you with the help of these storage mechanisms:
Standard HTTP Cookies
Local Shared Objects (Flash Cookies)
...
4
Actually, depending on the browser and plugins used, there are many ways for a website to store persistent information on users' computer. It's not cookies and cache anymore. Some of these new methods require user confirmation, some don't - it also varies by browser. Flash has Local Shared Objects, Silverlight has Isolated Storage, HTML5 itself gives Offline ...
4
The risks of Flash are client side. When viewing an compromised site that is well designed (not susceptible to XSS), there should be no difference in security between Flash and HTML 5 since the content is not malware. The main security problem with flash is for the client. When they visit a site infected with Flash based malware, bad things can happen to ...
3
Check out Fuzzing with DOM Level 2 and 3
"Overview
Fuzzing techniques proved to be very effective in finding vulnerabilities in web browsers.
Over time several valuable fuzzers have been written and some of them (mangleme, cross_fuzz) have became a "de-facto" standard, being widely adopted by the security research community.
The most common ...
3
Security advantages on the server side, or client side?
For serverside (hacking the server - getting access to the server files) I don't see any advantages to do either one or the other. They are both files that do nothing. If you use PHP or another serverside language, that may cause problems, but then it's PHP, not Flash or HTML5.
On the client side, ...
3
While "flash cookies" might be easy to clear as cx42net noted above, there are also other techniques that can be used to store hard-to-delete cookie-like data and read it from the server side.
Take a look at evercookie for reference. I've seen this used in relatively high profile e-commerce and content sites.
3
Since 6u10 Java applets have been able to store "muffins" (effectively cookies) using java.jnlp.PersistenceService.
Also from the same release, Java applets can also open files through FileOpenService, FileSaveService and ExtendedService.
3
You asked about alternatives. Quite frankly, this is a tough one: if someone is playing man-in-the-middle on your SSL session, and the user hasn't noticed or has allowed it to proceed, you're in a really tough spot. However, I'll try to brainstorm some alternatives that you could consider, if Javascript isn't able to check the cert the server provided on ...
2
Actually neither one of these is the "bigger" security concern. DOM XSS is the largest concern as there is no real practical prevention against it. Also, trying to protect yourself by setting up a large white list of sites is going to cause more headaches than not. The recommendation is have one box for fun and one box for personal matters such as ...
2
i think, to block both are not better solution than, keep your system, flash engine, and antivirus updated. Flash and Javascript are not more dangerous than any other application in your computer. They had bugs? Yes, they were fixed? Yes. As your browser, as your operational system and as every single piece of software. With flash blocked. you should know ...
2
Given your threat model (detect a proxy that proxies SSL but doesn't try to tamper with your checking code), you could embed Javascript code in all of your pages that checksums the content and compares it to a hardcoded checksum computed by the server, to determine whether the page that reached the client matches what the server sent. However, I suspect ...
2
I don't know. I'm not Michael Zalewski, and I can only speculate about the basis behind this advice. Did he say anything more in the book?
The crossdomain.xml file contains policy that Flash uses to determine how other sites may interact with this site. If it contains a permissive policy, then bad things can happen. Therefore, you don't want users to be ...
2
Flash is jailed by the some-origin policy and can only act upon a site that loads the flash applet with scripting access enabled.
However, flash can become a vector for XSS. The demo above lists various XSS vectors. So for example in the extremely unlikely condition where you are loading a flash applet where the attacker can control the loadMovieNumVar ...
2
Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership
2.4.1. Abusing Flash’s crossdomain.xml
The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively ...
2
There is a lot of exploits against libjpeg for sample. Who could be triggered even without javascript.
100% sure don't exist anyway, but. Each functionality present in your host are subject to security faillure and related exploit.
While quantity of faillure existing or maybe existing is related to complexitiy of software, more a functionality is complex ...
2
As reported here (04/16/2011), it's now easy to delete flash cookies as browser cookies :
The "Flash cookies", also known as local shared objects, can now be deleted through users' browser settings'.
And this, since the v10.3 of Adobe Flash Player. (see the release notes)
1
I know of a few security advantages that HTML 5 has when compared to flash and one disadvantage,this answer may not be complete
-HTML 5 updates are delivered through browsers hence there is a greater chance of users updating to the latest patch(as opposed to flash's 3rd party plugins that require separate updates)
-i believe that HTML 5 access to system ...
1
Depending on what the virus payload intends to do, Admin escalation and OS infection is not even necessary for it to do its job. Lots of things that crimeware is interested in happens in UserSpace, so all you need is access to the user account and session to reap most banking transaction credentials and then contact command and control through HTTP/HTTPS.
...
1
Here is an answer from Michal Zalewski that I received from email:
The concern is that is that Flash can be pointed to any URL to
interpret it as crossdomain.xml; so for example, if you allow users to
upload images, download CSV reports for their data, or host any other
sort of attachments or generated text files, you are at risk.
Requiring the ...
1
Everything here depends on the version of your Flash Player. Here's a list of stuff, which you should try on this .swf file.
Our first guess was Cross Site Scripting so we should try our hand at XSS, especially that we noticed one of the unsafe method: loadMovie.
Cross Site Scripting
There are a few types of unsafe functions. Each of them has different ...
1
With regard to Flash issues, every site that doesn't use Flash should use one of the two files at the root of the web server named crossdomain.xml. This will prevent XSS via that plugin
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy ...
1
The question here is who creates more secure software? The people creating the browser or Adobe?
They are pretty much equal, especially with all the HTML 5 stuff. Usually you need to enable JavaScript for Flash, so you could so you add Flash as a potential bringing additional attack vectors.
Only top voted, non community-wiki answers of a minimum length are eligible
