Apple Adds Anti-Hacker Features to QuickTime (via eWeek)

Apple Adds Anti-Hacker Features to QuickTime (via eWeek)

Faced with a security crisis affecting its media player, Apple responds with key exploit prevention mechanisms aimed at thwarting hacker attacks.

Apple is quietly adding several key anti-hacker security features into its flagship QuickTime media player as part of a deliberate plan to reduce the effectiveness of malicious exploits.

The XPMs (exploit prevention mechanisms) have been fitted into the WIndows and Mac OS X versions of QuickTime 7.4.5, a new update that also patches 11 high-risk security vulnerabilities.

According to a source familiar with Apple’s moves, QuickTime for Windows Vista now features ASLR (address space layout randomization), a security technology that randomly arranges the positions of key data areas to prevent malware authors from predicting target addresses.

ASLR, which has been used by Apple to add code scrambling diversity to Mac OS X Leopard, is used in tandem with additional security features to reduce the effectiveness of exploit attempts.

Several open-source security systems – OpenBSD, PaX and Exec Shield – already implement ASLR in some form. Microsoft has also fitted ASLR into default configurations of Windows Vista.

In addition to ASLR, QuickTime for Windows will also do stack buffer safety checking (Visual Studio 2005’s /GS option) and support for hardware NX on Windows Vista.

The security hardening has also extended to QuickTime for Mac OS X, which gets:

1. Stack buffer safety checking (-fstack-protector to gcc)

2. Function call hardening, which should prevent some buffer overflows

Security researchers reacted to Apple’s move with applause. “That’s a pretty big change for a point release,” said Dino Dai Zovi, a hacker who has written multiple exploits for QuickTime. “They [Apple] have way more guts than many other software companies to do something like that. Either that, or they are afraid of the backlash if malware starts targeting QuickTime and iTunes in a more serious way.”

Dai Zovi, who used a QuickTime exploit to hack into a MacBook Pro machine at the 2007 CanSecWest security conference, said the decision to enable the use of ASLR and NX on Vista will hamper exploits.

“QuickTime looks like it may have just gotten more difficult. That is definitely a good thing,” Zovi said.

Renault: We need to deliver for Alonso (via itv-f1)

Renault: We need to deliver for Alonso.

New Botnet Dwarfs Storm (via slashdot)

New Botnet Dwarfs Storm (via slashdot)

ancientribe writes:
“Storm is no longer the world’s largest botnet: Researchers at Damballa have discovered Kraken, a botnet of 400,000 zombies — twice the size of Storm. But even more disturbing is that it has infected machines at 50 of the Fortune 500, and is undetectable in over 80 percent of machines running antivirus software. Kraken appears to be evading detection by a combination of clever obfuscation techniques that hinder its detection and analysis by researchers.”

Sin comentarios…

FinderPop’s Review at MacWord

FinderPop has been reviewed at MacWord by Dan Frankes. You can read the review here. I don’t need to say how happy I am about it ;)

REPOST: Ode to Security Researchers

REPOST: Ode to Security Researchers:

After reading some articles (not only: ‘Linux Ignored, Not Immune,’ Says Hacker Contest Sponsor), I have decided to repost a previous entry ;-) In my opinion, the same applies to some journalists, bloggers, software developers, et cetera…

By Martin Pittenauer – 0×2a: Ode to security researchers

 “Dear security researchers, that…

• don’t prance around like a pwnie over every 0day
• value responsibility and public interests over your own ego
• have grown up
• don’t complain about people who haven’t, all the time
• understand software development processes and the meaning of “trivial”
• don’t insist on being baby-sitted 24/7 by $BIG_COMPANY
• aren’t at the center of the universe
• can resist making cheap jokes
• have written code worth mentioning, to broaden your horizon
• can make their outcome without having to pimp their personality, sell stuff to questionable characters or use tactics akin to extortion
• face discussion instead of declaring everybody else stupid
• don’t try so very hard to be a cool kid

…, I wish there were more of you.”

Well, as an open-mined person, I have decided to transcript this to your consideration…

Linux Foundation Publishes Study on Linux Development Statistics

Linux Foundation Publishes Study on Linux Development Statistics: Who Writes Linux and Who Supports It.

ANNOUNCEMENT: The Future of Epiphany

ANNOUNCEMENT: The Future of Epiphany (edit: the Gnome web browser)

“(…)This single back-end will be * WebKit *.

We see several advantages in WebKit. These include:

* The WebKit APIs. The API has been designed from the ground up, and
feels like any other GObject based API. A two-way GObject bindings to
the web page’s DOM, and to JavaScript is in development;
this will allow us and our Extensions to access the DOM directly, which
hasn’t been possible before in Epiphany in either C or Python.
* WebKit uses Gnome technologies directly. Similarly to Gecko, it uses
Cairo for graphics, and Pango for the rendering. On top of that, it uses
libsoup for the network layer, and GStreamer for the <video> and <audio>
tag support in HTML5.
* Starting in time for Gnome 2.24, WebKit/GTK+ will implement a
6-month release cycle synchronised with the Gnome release schedule.
* We feel that WebKit has the momentum, and can bring more developers
to both Epiphany directly and the Gnome platform by extension.
WebKit/GTK+ already has more people working on it than are working on
either GtkMozEmbed or the Epiphany gecko back-end.
* WebKit is a better match for *other* uses in Gnome, e.g. as a HTML
widget in Yelp, in Devhelp, and as an editor in Evolution replacing
GtkHTML.
We will propose WebKit as an approved external dependency for Gnome.
In case that we are unable to complete this development in time for
2.24.0, we will delay the new Epiphany to 2.26. For this end, we will
maintain the gnome-2-22 branch in a state that allows us to potentially
make the 2.24.0 release off of that branch.”

The performance aspect of Acid3 (via Hixie’s Natural Log)

The performance aspect of Acid3

The Acid3 test says “To pass the test, a browser must use its default settings, the animation has to be smooth, the score has to end on 100/100, and the final page has to look exactly, pixel for pixel, like this reference rendering”. (Emphasis mine.)

There has been some question as to what “the animation has to be smooth” means.

The idea is to make sure that browsers focus on performance as well as standards. Performance isn’t a standards-compliance issue, but it is something that affects all Web authors and users. If a browser passes all 100/100 subtests and gets the rendering pixel-for-pixel correct (including the favicon!), then it has passed the standards-compliance parts of the Acid3 test. The rest is just a competition for who can be the fastest.

To determine the “score” for performance in a browser that gets 100/100, click on the “A” of “Acid3″ on the test after having run the test twice (so that the test uses the browser’s cache). An alert should pop up, giving a total time elapsed, and reporting any tests that took longer than 33ms. Test 26 is the only one that should take any significant amount of time, as it contains a tight loop doing some common DOM and JS operations. The test has “passed”, for the purposes of the “smoothness” criteria, if all the tests took less than 33ms (it’ll give you a message saying “No JS errors and no timing issues.” if this happens). Then the only issue is the total time — is it faster than all the other browsers?

An important question is “using what hardware?”. Performance tests vary depending on the hardware, so some “reference platform” has to be picked to make a decision. Since “computer” browsers are the first priority with Acid3, as opposed to browsers for phones or other small devices, and since we want the hardware to be able to run the three major platforms of today, I have decided that the “reference hardware” is whatever the top-of-the-line Apple laptop is at the time the test is run.

As hardware improves, performance improves too, so to take this into account test 26 is set up to take longer and longer over time. Today I calibrated the test so that the performance it expects is plausible and will remain so for the next few years, based on results that browsers get on the past few years of Mac laptops.