Ola.

Heute Update-Tag bei Apple. Vielleicht kommt ja auch noch 10.6.7

Das hoffe ich doch mal stark, dann lohnt sich der Neustart wenigstens

Könnte ich mir gut vorstellen

OH wow was ist denn heute los! Wie Weihnachten

@Lars: :hehehe:

Und was meint ihr, ist safari endlich wieder schnell?

Zu zeit nutze ich chrome. Das lief bisher welten schneller.

Läuft, merke aber keinen Unterschied. Scrollen ruckelt etwas mit dem mTrackpad, war aber vorher glaube auch nicht ganz so sanft wie aufm iPad.

APPLE-SA-2011-03-09-2 Safari 5.0.4

Safari 5.0.4 is now available and addresses the following:

ImageIO
Available for: Windows 7, Vista, XP SP2 or later
Impact: Multiple vulnerabilities in libpng
Description: libpng is updated to version 1.4.3 to address multiple
vulnerabilities, the most serious of which may lead to arbitrary code
execution. For Mac OS X v10.6 systems, this is addressed in Mac OS X
v10.6.5. For Mac OS X v10.5 systems, this is addressed in Security
Update 2010-007. Further information is available via the libpng
website at http://www.libpng.org/pub/png/libpng.html
CVE-ID
CVE-2010-1205
CVE-2010-2249

ImageIO
Available for: Windows 7, Vista, XP SP2 or later
Impact: Visiting a maliciously crafted website may lead to an
unexpected application termination or arbitrary code execution
Description: A heap buffer overflow issue existed in ImageIO's
handling of JPEG images. Visiting a maliciously crafted website may
lead to an unexpected application termination or arbitrary code
execution.
CVE-ID
CVE-2011-0170 : Andrzej Dyjak working with iDefense VCP

ImageIO
Available for: Windows 7, Vista, XP SP2 or later
Impact: Viewing a maliciously crafted TIFF image may result in an
unexpected application termination or arbitrary code execution
Description: A buffer overflow existed in libTIFF's handling of JPEG
encoded TIFF images. Viewing a maliciously crafted TIFF image may
result in an unexpected application termination or arbitrary code
execution.
CVE-ID
CVE-2011-0191 : Apple

ImageIO
Available for: Windows 7, Vista, XP SP2 or later
Impact: Viewing a maliciously crafted TIFF image may result in an
unexpected application termination or arbitrary code execution
Description: A buffer overflow existed in libTIFF's handling of
CCITT Group 4 encoded TIFF images. Viewing a maliciously crafted TIFF
image may result in an unexpected application termination or
arbitrary code execution.
CVE-ID
CVE-2011-0192 : Apple

libxml
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a maliciously crafted website may lead to an
unexpected application termination or arbitrary code execution
Description: A double free issue existed in libxml's handling of
XPath expressions. Visiting a maliciously crafted website may lead to
an unexpected application termination or arbitrary code execution.
CVE-ID
CVE-2010-4494 : Yang Dingning of NCNIPC, Graduate University of
Chinese Academy of Sciences

libxml
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a maliciously crafted website may lead to an
unexpected application termination or arbitrary code execution
Description: A memory corruption issue existed in libxml's XPath
handling. Visiting a maliciously crafted website may lead to an
unexpected application termination or arbitrary code execution.
CVE-ID
CVE-2010-4008 : Bui Quang Minh from Bkis (http://www.bkis.com)

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a maliciously crafted website may lead to an
unexpected application termination or arbitrary code execution
Description: Multiple memory corruption issues existed in WebKit.
Visiting a maliciously crafted website may lead to an unexpected
application termination or arbitrary code execution.
CVE-ID
CVE-2010-1824 : kuzzcc, and wushi of team509 working with
TippingPoint's Zero Day Initiative
CVE-2011-0111 : Sergey Glazunov
CVE-2011-0112 : Yuzo Fujishima of Google Inc.
CVE-2011-0113 : Andreas Kling of Nokia
CVE-2011-0114 : Chris Evans of Google Chrome Security Team
CVE-2011-0115 : J23 working with TippingPoint's Zero Day Initiative,
and Emil A Eklund of Google, Inc
CVE-2011-0116 : an anonymous researcher working with TippingPoint's
Zero Day Initiative
CVE-2011-0117 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0118 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0119 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0120 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0121 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0122 : Slawomir Blazek
CVE-2011-0123 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0124 : Yuzo Fujishima of Google Inc.
CVE-2011-0125 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0126 : Mihai Parparita of Google, Inc.
CVE-2011-0127 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0128 : David Bloom
CVE-2011-0129 : Famlam
CVE-2011-0130 : Apple
CVE-2011-0131 : wushi of team509
CVE-2011-0132 : wushi of team509 working with TippingPoint's Zero Day
Initiative
CVE-2011-0133 : wushi of team509 working with TippingPoint's Zero Day
Initiative
CVE-2011-0134 : Jan Tosovsky
CVE-2011-0135 : an anonymous reporter
CVE-2011-0136 : Sergey Glazunov
CVE-2011-0137 : Sergey Glazunov
CVE-2011-0138 : kuzzcc
CVE-2011-0139 : kuzzcc
CVE-2011-0140 : Sergey Glazunov
CVE-2011-0141 : Chris Rohlf of Matasano Security
CVE-2011-0142 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0143 : Slawomir Blazek and Sergey Glazunov
CVE-2011-0144 : Emil A Eklund of Google, Inc.
CVE-2011-0145 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0146 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0147 : Dirk Schulze
CVE-2011-0148 : Michal Zalewski of Google, Inc.
CVE-2011-0149 : wushi of team509 working with TippingPoint's Zero Day
Initiative, and SkyLined of Google Chrome Security Team
CVE-2011-0150 : Michael Gundlach of safariadblock.com
CVE-2011-0151 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0152 : SkyLined of Google Chrome Security Team
CVE-2011-0153 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0154 : an anonymous researcher working with TippingPoint's
Zero Day Initiative
CVE-2011-0155 : Aki Helin of OUSPG
CVE-2011-0156 : Abhishek Arya (Inferno) of Google, Inc.
CVE-2011-0165 : Sergey Glazunov
CVE-2011-0168 : Sergey Glazunov

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: HTTP Basic Authentication credentials may be inadvertently
disclosed to another site
Description: If a site uses HTTP Basic Authentication and redirects
to another site, the authentication credentials may be sent to the
other site. This issue is addressed through improved handling of
credentials.
CVE-ID
CVE-2011-0160 : McIntosh Cooey of Twelve Hundred Group, Harald
Hanche-Olsen, Chuck Hohn of 1111 Internet LLC working with CERT, and
Paul Hinze of Braintree

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a maliciously crafted website may lead to cross-
site style declarations
Description: A cross-origin issue existed in WebKit's handling of
the Attr.style accessor. Visiting a maliciously crafted website may
allow the site to inject CSS into other documents. This issue is
addressed by removing the Attr.style accessor.
CVE-ID
CVE-2011-0161 : Apple

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: A maliciously crafted website may be able to prevent other
sites from requesting certain resources
Description: A cache poisoning issue existed in WebKit's handling of
cached resources. A maliciously crafted website may be able to
prevent other sites from requesting certain resources. This issue is
addressed through improved type checking.
CVE-ID
CVE-2011-0163 : Apple

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a malicious website and dragging content in the
page may lead to an information disclosure
Description: A cross-origin issue existed in WebKit's handling of
HTML5 drag and drop. Visiting a malicious website and dragging
content in the page may lead to the disclosure of information from
another website. This issue is addressed by disallowing drag and drop
across different origins.
CVE-ID
CVE-2011-0166 : Michal Zalewski of Google Inc.

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a malicious website may lead to files being sent
from the user's system to a remote server
Description: A cross-origin issue existed in WebKit's handling of
windows. Visiting a malicious website may lead to files being sent
from the user's system to a remote server. This issue is addressed
through improved tracking of origins.
CVE-ID
CVE-2011-0167 : Aaron Sigel of vtty.com

WebKit
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8,
Mac OS X v10.6.5 or later, Mac OS X Server v10.6.5 or later,
Windows 7, Vista, XP SP2 or later
Impact: Visiting a malicious website while using the Web Inspector
may lead to a cross-site scripting attack
Description: A cross-origin issue existed in WebKit's handling of
the window.console._inspectorCommandLineAPI property. Visiting a
malicious website while using the Web Inspector may lead to a cross-
site scripting attack. This issue is addressed by disallowing access
to window.console._inspectorCommandLineAPI from the web.
CVE-ID
CVE-2011-0169 : Apple

Wow - watt für'n Text!
Da kann man doch gleich mal das Scrollen testen

Arrrgggggg .... Und dafür den Rechner neu starten! AUTSCH!

Das ich bei jedem Safari Update immer den Rechner neu starten muss, versteh ich bis heute nicht...

phranck
Es wird ja nicht nur Safari aktualisiert, sondern auch das WebKit-Framework, auf dem Safari und andere OS X-eigene Programme (wie z.B. Mail) aufsetzen. Damit es da nicht zu Problemen kommt, ist der Neustart nötig

safari greift tief ins system ein, deshalb der neustart.

Apple TV und iPad Keynote Update gibt's auch!!

phrank:

Safari ist lediglich das GUI auf das WebKit-Framework. Dieses WebKit-Framework ist tief im System verwurzelt und verteilt sich auf verschiedene Verzeichnisse (ganz ähnlich und aus ähnlichen Gründen wie der Internet Explorer in das Windows-System integriert ist und auch aufgeteilt ist in ein Framework und quasi das Browser-GUI).
Hauptsächlich sind's diese Verzeichnisse, die das WebKit-Framework ausmachen.

/System/Library/Frameworks/WebKit.framework
/System/Library/Frameworks/JavaScriptCore.framework

Und dieses WebKit-Framework, das wird nicht nur von Safari genutzt, sondern die MacOSX Hilfe-Funktion nutzt es, iChat nutzt es, Mail nutzt es, Dashboard, Wörterbuch, Growl, XCode nutzen es.

Bei einem Update von Safari wird also dieser ganze WebKit-Stack erneuert und ausgetauscht. Geht aber nur dann, wenn keines der genannten Programme gerade auf diese betreffenden dateien dieses Frameworks zugreift. Apple könnte es z.B. so machen, dass sichergestellt wird, dass keines dieser mit dem WebKit-Framework verbundenen Programme gerade läuft und wenn eines läuft es dann zwangsbeendet wird oder das System den Nutzer bittet, das betreffende Programm doch bitte zu schließen. Dann würden die Dateien und Bibliotheken ausgetauscht, und dann werden diese einzelnen Programme wieder gestartet, wobei sie das dann mit diesen gerade aktualierten Dateien machen. Könnte Apple machen. Birgt aber die Gefahr, dass gewisse Bindings zu bestimmten feststehenden und dynamisch gelinkten Bibliotheken, für die MacOSX einen Cache im RAM und auf der HD anlegt, noch die alten Bibliotheken im Speicher haben. Dieser Cache müsste gleichzeitig auch erneuert werden. Das alles wäre kompliziert und würde Risiken beinhalten, dass irgendwas nicht ganz so sauber abläuft. Also geht Apple den zwar etwas radikaleren aber bzgl. Bibliotheken-Cache & Co. saubereren Weg und fordert einen Neustart ein, der sicher gewährleistet, dass mit dem Neustart auch wirklich alle neuen bzw. ersetzten Bibliotheken so geladen werden wie sie es sollen und es sich nirgendwo eine ältere Datei im Speicher oder sonstwo befindet, die da nicht hingehört.

Der Neustart in diesem Fall ist also eine für den Benutzer bequemere und sicherere Variante als die erste Methode, die man zur Vermeidung eines Neustarts auch machen könnte, dazu aber der Benutzer wahrscheinlich mehr eingebunden sein müsste, indem im Zusammenspiel mit dem Benutzer sichergestellt würde, dass keine Komponente des Systems grad' auf irgendeine Bibliothek des WebKit-Frameworks zugreift, um dann die dateien austauschen zu können und dann dem Benutzer das Zeichen geben zu können "So, ich bin fertig, habe alles ausgetauscht, Du kannst die Anwendung jetzt wieder starten und weiterbenutzen". Da ist einem ein kurzer Neustart (der ja auch schnell erledigt ist) doch lieber. Oder? Und wenn's grad' nicht passt, weil man mitten im Workflow ist, ja dann muss das Update halt noch ein paar Minuten oder Stunden warten, bis man fertig ist mit dem was man tut. Nirgendwo steht geschrieben, dass ein Update unmittelbar und sofort getätigt werden muss.

OK! Hat schon jemand Erfahrungen mit Glims 1b27 und Safari 5.0.4?
Irgendwelche Probleme? Oder kann ich das Update getrost installieren ohne das mir die super Funktionen von Glims — welche ich nicht mehr missen möchte — nicht mehr zur Verfügung stehen. Danke!

Und da sind sie wieder, die Nasen, die sich über einen Neustart ärgern. Ich verstehe es nicht und werde es auch niemals verstehen was an einem Neustart so furchtbar schlimm ist!

Also das Programm ist nach wie vor Sacklangsam, keine Ahnung warum. Nach dem eh schon langen Start dauert es zunächst ewig bis der Browser mal eine Seite öffnet, nicht selten sieht man während des Ladevorgangs sogar den Sat Ball. Erst wenn das Programm seine (meine) Seiten die ich als Favoriten abgespeichert habe im Hintergrund alle aktualisiert hat läuft es etwas geschmeidiger. Cache löschen bringt auch nicht so viel.
Und zum Chrome der zwischenzeitlich zu meinem Hauptbrowser mutiert ist ist er aber selbst dann noch meilenweit in Sachen Geschwindigkeit entfernt. Also hier muss sich Apple echt etwas einfallen lassen.
Im übrigen zeigt das Verhalten von Safari auf meinen beiden Rechnern hier keine signifikanten Unterschiede in seinem Verhalten.

hallo, bei ist Safari nicht wirklich schneller geworden.

Es würde sich für diejenigen anbieten, die da meinen, es sei langsam, den Browser zurückzusetzen.

Safari kann man langsam rauchen. die ersten Versionen von Safari waren mal schnell.

Google Chroma kann safari nicht annähernd das Wasser reichen. schade.

DP_70
Und ich wundere mich immer wieder über die phantasielosen Nasen, die sich nicht vorstellen können, dass ein Neustart ziemlich lästig sein kann.
Für mich bedeutet ein Neustart erstmal eine gewisse Neuorientierung bei mehreren in Bearbeitung befindlichen Projekten mit etlichen geöffneten Dokumenten und Programmen. Für User, die ausschließlich mit Surf- und Dattelambitionen an ihrem Mac sitzen - kein Problem.

@sitox. genau so ist es... Ein OS X sollte nie neugestartet werden. bei mir habe ich Uptimes von mehreren Monaten. Viele Projekte und einige Programme sind da offen.

dafür kommt in Lion ja dann der Resume Modus, damit alles da ist wo es vorm Neustart war

Danke SIERKB für die gute Erklärung

Alter Schwede!
Wenn man sich APPLE-SA-2011-03-09-2 für Safari 5.0.4 mal so durchliest, dann ist Safari ja bis heute abend eine einzige große, wandelnde Sicherheitslücke gewesen!
Vor allem die Anzahl der seit Anfang dieses Jahres 2011 (wir haben grad' mal eben März) in WebKit (vor allem von Google-Leuten) gefundenen und nun geschlossenen Lücken lassen mich ja ein wenig erschüttert erstaunen.

Ich glaube, soviele per CVE-ID benannte und Gott sei Dank nun gefixte Sicherheitslücken hat Safari selten oder gar noch nie auf einmal gehabt. Oder täusche ich mich? Ob das evtl. auch etwas damit zu tun hat, dass die Black Hat-Konferenzen sich dieses Jahr sehr auf das iPhone/IOS und Android konzentrieren (in beiden wird ja WebKit verwendet) und man jetzt Apple und Google Gelegenheit gegeben hat, WebKit bzw. Safari und Chrome zu fixen, bevor man nach Abwarten einer mit den Herstellern vereinbarten "Gnadenfrist" Näheres zu den Lücken öffentlich sagt und ggf. Exploits und Proof of Concepts der Öffentlichkeit präsentiert?

Immerhin ist aus dem Umfeld das hier schon mal vorab zu lesen:

FSMdotCOM: SpyPhone: Demo Of Malware Spread Through Appstore At Black Hat Conference (04.02.2011)
FSMdotCOM: iPhone Apps Malware Is The Focus Of This Year’s Black Hat Conference (02.02.2011)

Keine sehr beruhigenden News für iPhone-Besitzer. Was Android-Nutzern passieren kann, davon sind iPhone-Besitzer also dann wohl auch nicht weit entfernt bzw. kann ihnen passieren. Trotz Apples Türsteher-Rolle am App-Store-Eingang, die im Sinne der Sicherheit so wirkungsvoll dann wohl auch nicht zu sein scheint wie allgemein angenommen, wenn man diesen Erkenntnissen der Black-Hat-Teilnehmer Glauben schenken darf.

sierkb

Weshalb sollten angekündigte Diskussionsthemen auf einer Hackerkonferenz beunruhigende News für iPhone-Besitzer sein? Es ist doch ganz normal, dass Hacker iOS attakieren?

Tatsache aber ist, dass es, dank der Kontrolle von Apple, bisher noch nicht zu gröberen Problemen gekommen ala Android gekommen ist.

Ich finde diese Hackerkonferenzen sehr gut, denn sie zeigen Apple, wo noch Handlungsbedarf besteht. Und wie sich mit den aktuellen Updates zeigt, wirkt der Druck bereits.

Leider wurde an der Black Hat der Safari 5.0.3 attackiert und nicht die aktuelle Version 5.0.4.

Es wäre interessant gewesen zu sehen, ob der verwendete und erfolgreiche Angriff bei 5.0.4 auch funktioniert hätte.

Also an die Leute die ihren Mac produktiv benutzen:

Man installiert auch keine Systemupdates während der Arbeit, sondern entweder nachts oder am Wochenende.

Es zwingt euch ja keiner dazu, das oder die Updates sofort einzuspielen.

@barabas: lösch mal die plugins, vor allem adblock

Wenn man so viele wichtige Projekte offenbar immer "offen" haben muss, dann sollte man eben keine Systemupdates fahren während der Arbeit.

Zudem würde ich mal die Arroganz ablegen und alle, die ihren Mac regelmäßig herunter fahren oder neu starten als reine Spiel- und Surfnutzer zu bezeichnen.

Und selbst wenn ein Neustart ach so schlimm ist, dann nervt es einfach dies bei jedem Systemupdate erneut in den Kommentaren kund zu tun.

Das man OS X nie neustarten sollte ist natürlich Unfug. Genau so wäre es Unfug von mir zu behaupten, man muss es einmal am Tag neu starten. Das manche auf ihre "Uptimes" offenbar sogar stolz sind, finde ich albern.

was mir beim update aufgefallen ist: mein oller g4 (leopard) lädt das ganz normal so schnell wie es die leitung halt zulässt. mein deutlich neueres mb (snow leopard) lädt etwa 500kb/s schneller, als es eigentlich möglich sein sollte. und noch seltsamer: es verschickt auch noch etwa ebenso viele daten!

was geht da ab?