Protecting over 200 million PCs, Macs, & Mobiles – more than any other antivirus

June 20th, 2011

Fear of the HTML5

Right at the beginning of this article – I must admit that I’m definitely not a specialist for the newest trends in web development. Consider following contemplation only as a thinking of an amateur. Today I’ve noticed an article about the first MP3 codec written in JavaScript ( in order to support this media format in all browsers (even when they have no native support/codec for such media). Sounds great for such kind of  inexact specification like <audio> and <video> tags, that can encapsulate variable media formats. The particular media format does not matter (MP3, OGG, FLAC etc.), the only thing you need is to provide a codec.

And here begins the chain of my concerns. Remember, I’m not a specialist on this topic, thus… everything written here might be a complete nonsense. But I can imagine a scenario:

  1. prepare a specially crafted “media” file – generally an encrypted file with a shellcode/payload
  2. encapsulate its reference in an <audio> tag
  3. have a JavaScript close at hand.. it will carry the decryption of the “media” file content and the exploitation, subsequently followed by the malcode execution.. the goal is that the JavaScript will be called as a regular codec for the specified media file

Does it sound impossible to you? Use the comments section below to share your opinions. I’m quite afraid of such a huge door open for new ways of exploitation/infection.

  • yanto chiang

    Hi Michal,

    It was looked this web put API into their site as audio player,

    According to Acunetix Web Vulnerability Scanner scan summary this site has open some ports such as port 22/SSH, port 25/SMTP, port 53/domain, port 80/http, port 110/pop3, port 111/rpcbind, port 119/nntp, port 143/imap, port 465/smtps, port 563/snews, port 587/submission, port 993/imaps, port 995/pop3s, port 3000/ppp, port 4000/remoteanything. And this website DNS Server running under port 53/domain and not detected have any vulnerability yet.

    But according to google anaylisis this site looks like using APIv1 which’s this application version will turn off and will released APIv2. This site probably could be injected with phising and malware site if their service not always patch.

    Here is the link of google analysis :

    Yanto Chiang

  • Michal Krejdl

    @yanto chiang
    Yanto, this particular site is only an example. What I’m afraid of is the abuse of the principle/technology. You know, there are always two sides of the coin – and this can be considered either as a feature or as a vulnerability IMHO.

  • Fernando Gregoire

    Well, I am only a user. But acording to my little understanding about this topic, HTML 5 is a standard that only need to be supported by the web brouser, therefore I think this tipe of player unnecessary.
    Respect to security issues, the HTML 5 standard is relatively new and its exploitation hasn’t been started. But when the standard reaches a grade of popularity, is obvious that cybercriminals will try to find vulnerabilities; in this case the web brousers manufacturers will have to submit patches to be downloaded by the users, this has not been changed.
    The advantage that I see on HTML 5 is that as this standard have native audio and video capabilities (only need to be supported by the web browser), additional plugins such as Flash, Java and Silverlight will not be necessary, so we’ll have less components requiring security updates.

  • igor

    I’m afraid this is not about unintentional vulnerabilities and their exploitations – but rather about the actual DESIGN. If the thing is designed in such a way that it’s easy to abuse, there is no fix or patch for that – you’d have to change the whole concept (which may be hard to do).

  • Petr B

    Hi Michal,
    HTML5 doesn’t come into it neithr codecs do. A javascript can access a page’s data, it can do things with it, no matter if the data is mp3/image/text/raw data. Javascript can also fetch data from web and send data to web (via XMLHTTPRequest or whatever it is called). The idea is that it can only access the same web-server it originates from. Javascript also cannot access local hard-drive. Therefore if all works as it should we are safe. The principle/technology is sound and safe. Unfortunatelly there will be vulnerabilities in web browsers now and then. Luckily we haven’t got the monoculture we used to have a few years ago…


  • Fernando Gregoire

    Hi petr.
    You have reason. And although the browser vulnerabilities still have allow infections via Javascript, luckily Avast have the Script shield.

  • Michal Krejdl

    @Petr B
    That’s only one side of the problem (isolation from cross-server references and local system). What I meant is a fact that there will probably arise two new ways how to bind JavaScript malcode execution to new objects (codecs for and ). In case of built-in codecs is everything verified by the browser developer. In case of binary plugins you have the opportunity to easily check their origin/reputation/digital signature and approve them depending on your findings. But what about JavaScript codec bound to an tag? It may contain whatever the author wants (or it could be unintentionally injected) and there’s no digital signature etc. and there’s no option to allow/disallow the particular JavaScript codec afaik.

  • temizlik

    thank you for your information…

  • JN

    hola como están espero que bien saludos cordiales, yo me preguntaba xq avast su definición de virus a disminuido hace poco era un poco mas de 3 millones y ahora esta en mas de 2 millones 800 y hace varios días mas el web rep no sirve en firefox 5.0 y quisiera saber para q fecha estará disponible también me gustaría saber como hacer para que avast hable en japonés yo se japonés y también una tía mía habla japonés y quisiera saber como hacer para que el antivirus hable en japonés y xq el auto sandbox de avast marca a ares como un programa para virtual izar y si es posible como sugerencia xq en esta nueva característica de avast auto sandbox no hacen una función automática algo parecido al escudo de comportamiento y otra sugerencia que podría ser útil los sitios web que uno quiere bloquear como avast tiene un bloqueo de url xq no facilitan si es posible a través del web rep o algo parecido una opción que aparezca en el navegador y que diga bloquear url y que automáticamente el sitio web se pueda bloquear de una forma mas fácil esta función podría funcionar con el web rep que aparte de lo que trae traiga una función que uno o que el usuari@ active la misma para bloquear o desbloquear el sitio web (url).

    Por otra parte los felicito por tan buen programa antivirus han hecho un excelente trabajo sigan así avast software.