Houston, we have a Hole!

O que mais me intriga é o porque de fazer tal concursos. Ao menos depois divulgam como corrigir o problema?

Ainda não tive tempo de procurar saber mas a questão é saber se foi o "exploit" corrigido ontem. ;)

EDIT: Afinal não... é novo:

No sooner said... the first half of the CanSecWest MacBook Pro hack challenge has been won, with an exploit that uses a malicious webpage to gain a user-level shell via Safari.

The vulnerability and exploit were developed last night by Dino Dai Zovi, in the wake of an announcement by 3Com establishing a $10,000 bounty on successful exploitation of one of the contest MacBooks. Said Dino: “I think I may have set the land-speed record”.

Ou já tinha esta na manga ou temos o recordista mundial do exploit em Macs. ahah!
 
Última edição:
Será que agora vão deixar o Windows em paz e virarem se para o MAC? ao menos assim ganham dinheiro :002:

:lol:

just kidding
Assim também eu gostava de ganhar...
 
[PT]latrine;1576087 disse:
Posi e o meu update parece que correu mal...estou com o mac no ecrã azul com a rodinha à mais de meia hora...

É por causa dessas coisas que só faço os updates 5-7 dias depois deles sairem, só por causa das tosses....


Quanto a este exploit, não somos invulneráveis, basta haver motivação (neste caso eram 10000$ e um MacBook Pro) e Know-How e isto era inevitável acontecer. Mas pelo pouco que ainda consegui perceber (ainda há pouca informação) o utilizador tem que carregar uma página no Safari (é uma fraqueza especifica do Safari) que por sua vez despoleta todo o processo de acesso ao sistema com privilégios de utilizador, a 2ª parte do concurso é para conseguir root access... e esta fase ainda ninguém conseguiu alcançar. Portanto, até a Apple lançar novo update de segurança usem Firefox, Opera, Camino, OmniWeb, Lynx, Shiira, esqueci-me de de algum?:lol:
 
[PT]latrine;1576150 disse:
foi só um restart froçado e está tudo a 100%... ufa!

Faz um repairPermissions e um check ao disk com o disk util a partir do DVD (boot pelo DVD). Deves ter algum ficheiro "pendurado".
 
Afinal parece que o buraco está no Java. Neste caso qq browser é afectado. E puff lá se vai o interesse e é mais um deja vu.

Defending Against the CanSecWest Mac Exploit: Turn Off Java ?
Thomas Ptacek has the scoop: Dino Dai Zovi’s winning exploit in the CanSecWest contest involves Java. It is not specific to Safari; Firefox – and, I presume, Camino – are also vulnerable. Turning off Java in your browser should defend against it.

In a comment on Ptacek’s weblog entry, Dai Zovi himself writes:

With any 0day bug, there is a ton of conflicting information in what it is in and what is affected. I obviously don’t want to say too much so as to hint as to where the bug is until a patch is released. I will say that applying slightly paranoid web browser configuration changes will prevent this vulnerability from being exploited.

And no, I have not been sitting on this exploit, I really did find the vulnerability and write the exploit that night. I got lucky. I have spent way more time not finding bugs many other times.
 
ainda sobre o assunto aqui fica uma entrevista realizado por John Gruber ao hacker que descobriu o "buraco".

http://daringfireball.net/2007/04/interview_dino_dai_zovi

destaco:

Gruber: Do you use a Mac as your primary computer? If so, what security precautions do you take? I’m going to go out on a limb and predict you do not use any sort of commercial anti-virus package.

Dai Zovi: I use a Mac as my primary, secondary, and tertiary computers :). I take some extra security precautions such as always running as a non-admin account, using separate encrypted disk images and keychains for different purposes, and isolating data on different machines. I also take some extra precautions that I’m not going to advertise publicly :). I do not, however, run any commercial anti-virus packages.

Gruber: Are there any precautions you think typical Mac users should take that they aren’t now?

Dai Zovi: I would recommend they make their primary user account a non-admin user, I think that is a reasonable compromise between usability and security. I would also recommend that more security-conscious users create a separate keychain with a 5 minute timeout for important passwords. Even if the user is using FileVault, a separate encrypted disk image for sensitive financial or personal documents is another simple and prudent measure to protect your personal information.
 
buraco tapado:

http://docs.info.apple.com/article.html?artnum=305446

This document describes the security content of QuickTime 7.1.6, which can be downloaded and installed via Software Update preferences, or from Apple Downloads.

For the protection of our customers, Apple does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches or releases are available. To learn more about Apple Product Security, see the Apple Product Security website.

For information about the Apple Product Security PGP Key, see "How to use the Apple Product Security PGP Key."

Where possible, CVE IDs are used to reference the vulnerabilities for further information.

To learn about other Security Updates, see "Apple Security Updates."

QuickTime 7.1.6 Update

QuickTime

CVE-ID: CVE-2007-2175

Available for: Mac OS X v10.3.9, Mac OS X v10.4.9, Windows XP SP2, Windows 2000 SP4

Impact: Visiting a malicious website may lead to arbitrary code execution

Description: An implementation issue exists in QuickTime for Java, which may allow reading or writing out of the bounds of the allocated heap. By enticing a user to visit a web page containing a maliciously-crafted Java applet, an attacker can trigger the issue which may lead to arbitrary code execution. This update addresses the issue by performing additional bounds checking when creating QTPointerRef objects. Credit to Dino Dai Zovi working with TippingPoint and the Zero Day Initiative for reporting this issue.

Aposto que um nosso colega continuará a insistir que o buraco é no Safari e/ou no Java. :002:
 
Back
Topo