A software slipup in RealNetworks’ music player means that Windows, Mac and Linux computers could be compromised by a fake movie file, a security company said Friday.<\/p>\n","protected":false},"excerpt":{"rendered":"
The problem means that fake movie files could be created that, when played by vulnerable Real software, would run a program instead.<\/p>\n
The flaw appears in RealPlayer 10 for Windows and Mac OS X, the RealOne Player for Windows and Mac OS X and the Real Helix Player for Linux.<\/p>\n
“Anyone who has RealPlayer is affected, and there are many people with RealPlayer,” said Marc Maiffret, chief hacking officer at software security company eEye Digital Security, the company that discovered the security issue.<\/p>\n
RealNetworks could not be reached for comment.<\/p>\n
The flaw occurs in a component of Real’s software that handles Real movie files with the .rm extension, according to eEye’s advisory.<\/p>\n
Similar to the recent flaw in Windows applications that handle the JPEG image format, this vulnerability affects a widespread piece of software and could be used to create a virus.<\/p>\n
“It’s similar to the JPEG flaw in the sense that just by viewing the file, or having the file ‘force viewed’ through a Web browser, your system can be compromised,” Maiffret said.<\/p>\n
“I think both this JPEG vulnerability and the RealPlayer vulnerability are good examples of a type of threat that is becoming more prevalent: client-side vulnerabilities.”<\/p>\n
Rather than finding a security hole in the operating system and gaining direct access to a computer, attackers are now increasingly looking at exploiting widely used applications.<\/p>\n
Latest Bagle variant attempts download of potentially infected JPEG file alternatives other than patching,” Maiffret said.<\/p>\n
http:\/\/news.zdnet.com\/2100-1009_22-5393139.html?tag=default<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-2346","post","type-post","status-publish","format-standard","hentry","category-warnings"],"_links":{"self":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/2346","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=2346"}],"version-history":[{"count":1,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/2346\/revisions"}],"predecessor-version":[{"id":4833,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/2346\/revisions\/4833"}],"wp:attachment":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=2346"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=2346"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=2346"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}