It is admitted that drive-by download attacks occur only thanks to the user's interaction as it was the case, for instance, with the HDD Plus virus where visitors of the compromised website needed to double click at least on rad.msn.com banners.

But actually there have been drive-by download attacks that run successfully on IE, Safari, Chrome and Firefox without requiring the user's interaction. For instance, CVE-2011-0611 was a 0-day vulnerability up to April 13th, 2011 (meaning a short while before you asked this question). It was used to infect the homepage of the Human Right Watch website in UK. The infected page contains a rogue <script src=newsvine.jp2></script> element. This tricks the browser into caching and executing newsvine.jp2 as JavaScript code. It was a drive-by cache attack which is just a case of drive-by download attacks. The caching is successful, but the file cannot be executed as JavaScript because it is actually a renamed malicious executable corresponding to a backdoor from the pincav family.

Another rogue script element found on the infected page is <script src="/includes/googlead.js"></script>, which unlike most drive-by download attacks, loads a local .js file. The JavaScript code in googlead.js creates an iframe that executes the SWF exploit from a domain controlled by the attackers.

By the same year you asked this question, there was an other example of a drive-by download attack of which no browser was safe as long as they run a vulnerable version of JRE at that time (CVE-2011-3544). Thousands of visitors of the Amnesty International's homepage in UK were thus infected by Trojan Spy-XR malware. The attacks continued until June 2011, so later after you asked this question: Google Chrome was not safe of it.

A little bit more than two years later after this question, on October 24th, 2013, the famous php.net website has been infecting its visitors by a drive-download attack through a hidden iframe tag. The attack concerned also Google Chrome.

It is admitted that drive-by download attacks occur only thanks to the user's interaction as it was the case, for instance, with the HDD Plus virus where visitors of the compromised website needed to double click at least on rad.msn.com banners.

But actually there have been drive-by download attacks that run successfully on IE, Safari, Chrome and Firefox without requiring the user's interaction. For instance, CVE-2011-0611 was a 0-day vulnerability up to April 13th, 2011 (meaning a short while before you asked this question). It was used to infect the homepage of the Human Right Watch website in UK. The infected page contains a rogue <script src=newsvine.jp2></script> element. This tricks the browser into caching and executing newsvine.jp2 as JavaScript code. It was a drive-by cache attack which is just a case of drive-by download attacks. The caching is successful, but the file cannot be executed as JavaScript because it is actually a renamed malicious executable corresponding to a backdoor from the pincav family.

Another rogue script element found on the infected page is <script src="/includes/googlead.js"></script>, which unlike most drive-by download attacks, loads a local .js file. The JavaScript code in googlead.js creates an iframe that executes the SWF exploit from a domain controlled by the attackers.

By the same year you asked this question, there was an other example of a drive-by download attack of which no browser was safe as long as they run a vulnerable version of JRE at that time (CVE-2011-3544). Thousands of visitors of the Amnesty International's homepage in UK were thus infected by Trojan Spy-XR malware. The attacks continued until June 2011, so later after you asked this question: Google Chrome was not safe of it.

A little bit more than two years later after this question, on October 24th, 2013, the famous php.net website has been infecting its visitors by a drive-download attack through a hidden iframe tag. The attack concerned also Google Chrome.

Also you mentioned Google Chrome could be that safe because of its sandbox mechanism: well, all browsers are sandboxed, not only Google Chrome, but still they are vulnerable to drive by download attacks because of their own vulnerabilities or those of the plugins installed within them.