Laufenden Rechner vor Zugriff sichern

[Wolfram]

Hallo allerseits,

wenn ich die Systempartition auf einem Windows-Rechner per Truecrypt verschlüssele, ist der Rechner ja erst mal vor unerwünschtem Zugriff geschützt. Was aber ist, solange die Kiste läuft? Unterstellt, das Windows ist up-to-date, so daß bekannte Sicherheitslücken geschlossen sein sollte, wie sicher ist es, den Rechner per Windows-Logon-Passwort zu sperren? Alternativen?

TIA,

Wolfram

[Milton]

Also wenn Du Firewire hast, kannst Du das alles eh vergessen, es sei denn Du deaktivierst es im Bios. Siehe beispielsweise hier: http://computer.forensikblog.de/en/2008/02/acquisition_5_firewire.html
USB Autostart muss auch auf allen Laufwerken deaktiviert werden. Denn solche exploits sind wohl mittlerweile auf handelsueblichen Forensik Kits drauf.

Ansonsten ist die Frage: Gibt es ein Masterpassword fuer Windows? Und ist es moeglich, dass es bisher geheim blieb? Und dass man noch nichtmal von dessen Einsatz je gehoert hat?

Also ich denke: nein, zumindest nicht fuer Angriffe auf Otto Normalverbraucher. Auf Firmen oder Staatsebene muss man sich ja sogar ueber gehackte Biose/Firmwares gedanken machen. Fuer alle anderen sollte Windows-L sicher genug sein.

P.S. Wenn Du paranoid sein willst, gibt es so viele nette Szenarien wie Kamera, Hardware Keylogger und Ram in Fluessigstickstoff, bei denen Dir auch Truecrypt nicht hilft. Und es gibt ja sogar dieses eine Truecrypt rootkit, dass vor truecrypt geladen wird und dein Passwort liest, siehe zum Beispiel hier: http://simonhunt.wordpress.com/2009/08/04/truecrypt-vs-peter-kleissner-or-stoned-bootkit-revisited/

[Wolfram]

Also wenn Du Firewire hast, kannst Du das alles eh vergessen, es sei denn Du deaktivierst es im Bios. Siehe beispielsweise hier: http://computer.forensikblog.de/en/2008/02/acquisition_5_firewire.html
USB Autostart muss auch auf allen Laufwerken deaktiviert werden. Denn solche exploits sind wohl mittlerweile auf handelsueblichen Forensik Kits drauf.

Ah, das ist schon mal ein prima Hinweis, danke. Firewire ist nicht vorhanden.

Ansonsten ist die Frage: Gibt es ein Masterpassword fuer Windows? Und ist es moeglich, dass es bisher geheim blieb? Und dass man noch nichtmal von dessen Einsatz je gehoert hat?

Gibt es nicht, bisher. Das sollte ich also nicht vergeben?


Also ich denke: nein, zumindest nicht fuer Angriffe auf Otto Normalverbraucher. Auf Firmen oder Staatsebene muss man sich ja sogar ueber gehackte Biose/Firmwares gedanken machen. Fuer alle anderen sollte Windows-L sicher genug sein.

P.S. Wenn Du paranoid sein willst, gibt es so viele nette Szenarien wie Kamera, Hardware Keylogger und Ram in Fluessigstickstoff, bei denen Dir auch Truecrypt nicht hilft. Und es gibt ja sogar dieses eine Truecrypt rootkit, dass vor truecrypt geladen wird und dein Passwort liest, siehe zum Beispiel hier: http://simonhunt.wordpress.com/2009/08/04/truecrypt-vs-peter-kleissner-or-stoned-bootkit-revisited/

Klar, gegen solche Hardwareeingriffe oder Überwachungsszenarien bringt das eh alles nichts. Die Frage ist halt immer, ob man paranoid genug ist...;)

[Milton]

Gibt es nicht, bisher. Das sollte ich also nicht vergeben?

Hi, da hast Du mich falsch verstanden. Meine Frage war rhetorisch: hat der Staat oder irgendwer ein geheimes Universalpasswort, mit dem er den Windows-Lockscreen umgehen kann, also: gibt es da eine Backdoor. Falls Du nicht an eine Backdoor glaubst, ist der Lockscreen sicher. Du solltest aber alle Accounts mit Passwort schuetzen.

[(del)]

USB Autostart muss auch auf allen Laufwerken deaktiviert werden. Denn solche exploits sind wohl mittlerweile auf handelsueblichen Forensik Kits drauf.Was passiert denn damit, wenn der Rechner "gesperrt" ist? :|

[Milton]

Es gab mal USB Viren die trotz gesperrten Windows per autostart.inf geladen wurden. Keine Ahnung ob all die Loecher mittlerweile gefixt sind. Ich wuerd es sicherheitshalber abschalten.

[(del)]

Ja es ging mir nur um die "Technik" dahinter. Ausmachen sollte man das eh ;)

@Wolfram
Das Prob mit der Sicherheit ist, daß sie nicht eine Lösung, sondern ein Konzept ist :( und der ändert sich entsprechend nach den jeweiligen Gegebenheiten.

Sobald man irgendwo ein Passwort eingibt ist ein System eh sofort um Größenordnungen unsicherer =)

Im Bezug zu deinem "Problem" bzw. ergänzend, sollte man fürs Arbeiten nur den Eingeschränkten benutzen. Egal auf welchem Windows und ungeachtet UAC. Am gesperrten Eingeschränkten vorbei reinzukommen - vor allem dauerhaft - ist eine ganze Ecke schwieriger. Theoretisch gar unmöglich. Was praktisch geht verraten die Dienste nicht ;)
Wenn du dir diese Gedanken machst, sollte auch das Leeren der Auslagerungsdatei beim Runterfahren zum Konzepot gehören.

Im Gründe veränderst du damit fortlaufend nur die Art des lohnenden Angriffs. Wenn jemand schon den Zugriff auf die unbeaufsichtigte Räumlichkeit hat, und das System gut zugeknüpft ist, dann haut er dir eine Mikrokamera in die Deckenleuchte, die den Bildschirm abfilmt. Mit 230V Stromversorgung kann man wohl gleich wunderbar weit senden.

Am sichersten ist die Kiste halt, wenn die Steckdosenleiste länger als 30min. aus ist ;)

http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html

http://theinvisiblethings.blogspot.com/2009/05/thoughts-about-trusted-computing.html

http://simonhunt.wordpress.com/2009/08/04/truecrypt-vs-peter-kleissner-or-stoned-bootkit-revisited/

http://www.zdnet.co.uk/news/security-management/2008/07/17/schneier-research-team-cracks-truecrypt-39448526/

http://www.koreaittimes.com/story/13278/fbi-hackers-fail-crack-truecrypt
(Kann genausogut auch nur eine PR-Aktion sein. Benutzt es, es ist sicher ;) )

http://www.truecrypt.org/docs/?s=unencrypted-data-in-ram

[(del)]

Ich hab mich in der letzten Zeit mal mit einigen hardcore Mailinglisten beschäftigt und über paar Quelocdes drübergeschaut. Und auch mit paar Leuten gesprochen... Bei der Gelegenheit, weil ich mir paar Sachen selbst zusammengebacken habe (mit TDM). Dabei fiel mir nicht nur auf was für vermatschte Baustellen die Sources waren.

Was "Snow" mal meinte, daß man keiner sicherheitsrelevanten Soft vertrauen sollte die nicht von Leuten kommt die selbst Jahrelang Systeme gehackt haben, und dann auch nur wenn man deren Code versteht, ist ein absolut wahres Wort. Dieser Kanninchenbau ist ein echter Horrotripp.

Es gibt so wenig Code in freier Wildbahn der als diesbezüglich ausreichend eingestufft werden könnte, das macht echt Angst. Außer dem Kernel von OpenBSD, Apache und TrueCrypt (der sich aber mit den prinzipiellen Problemen seiner Platformen rumschlagen muß). Das sind so Teile, wo ich mal in Prozent sagen würde, die sind bis zu 70% wirklich sicher. Das sind jetzt die Spitzenwerte! KeePass vielleicht noch.

Und wenn du meinst, du hättest an alles gedacht, im Source, dann optimiert dir das der Compiler je nach Option einfach so WEG. Wer da nicht 7x bei den Disassemblaten nachschaut, der kann sich z.B. sein assert sonstwohin schieben.

Das ist wirklich erschreckend, wenn man da so wirklich einsteigt und es auch peilt.

Und die Story, daß open source sicherer ist, weil da immer mal jemand drüberschaut, ist ein perfides Märchen. Es schaut außer den oft schon betriebsblinden Entwicklern der Soft selbst, keine Sau drüber. Jedenfalls keine, die ein security issue finden könnte. EXTREM SELTEN. Der Gelbe der drüberschaut, der sagt keinem was, sondern nutzt es aus. Und die Möglichkeiten sind echt ungeahnt.

Real kann man ruhig davon sprechen, daß niemand irgendeine Kontrolle über Software hat. Niemand, wirklich niemand blickt 100% die Auswirkungen der Sources, denn sobald an alles gedacht ist und es ein halbes Jahr ruhe gibt, taucht plötzlich wieder jemand auf und steckt wieder die Finger in die Löcher. Und dann muß man auch schon die Soft erweitern oder umbauen und das Spiel fängt von vorne an. Oder es gibt eine neue Version vom GCC die Mist baut. Grad bei Linux je nach Distribution gibts zig Versionen vom GCC im Umlauf. Es ist nicht möglich Source rauszuhauen und zu sagen, hier, das macht das und das sicher. No fuck way.

Leute, es gibt KEINE Softwaresicherheit und keine sichere Software. Ehrlich. Der ganze Gedöns mit Sicherheit ist ein riesiger Seifenblasen-Fuckup. Vergißt das mit der Sicherheit. Entweder habt ihr ein unsicheres System und dann hilft garnichts oder ihr habt alles mögliche richtig gemacht und könnt dann auf eures GLÜCK hoffen.


p.s.:
Am besten macht das echt noch Cisco :D Die haben, so scheint es mir, eine ausgeklügelte Taktik Sicherheit durch Chaos zu erreichen. Die haben zwar immermal irgendwo ein Loch, fuchteln aber am Code und Optionen dermassen rum, daß ein Exploit höhstens auf eine Gerätecharge anwendbar ist bzw. eine einzige Minor =) Um das zu hacken muß genau das Gerät zuhaus haben und genau diese eine Minor aufspielen können. Eine verrückt geniale Idee. Falls sie so gewollt ist ;)

[mfq]

Und wenn du meinst, du hättest an alles gedacht, im Source, dann optimiert dir das der Compiler je nach Option einfach so WEG. Wer da nicht 7x bei den Disassemblaten nachschaut, der kann sich z.B. sein assert sonstwohin schieben.Naja, bei konformem Code wird einem der Compiler sicherlich nicht einfach mal irgendwelchen (nicht bewiesenermaßen toten) Code raushauen. Die Bedeutung des Programms darf der Compiler nicht verändern und wenn er nicht gerade einen fetten Bug hat, tut er das auch nicht.

Wer natürlich mit (x > x+1) auf einen möglichen Overflow prüfen möchte, wird sein blaues Wunder erleben. So geht das nicht, das kann der Compiler einfach durch FALSE ersetzen. Schlimmer noch: Laut C-Standard ist das Verhalten bei einem Signed Overflow undefiniert. Das bedeutet im C-Jargon nicht, dass das Verhalten an dieser einen Stelle nicht vorhersagbar ist, sondern dass das gesamte Programm völlig wertlos ist. Der Compiler wäre durchaus im Recht, würde er Code emittieren, der die Festplatte formatiert oder Dämonen aus deiner Nase fliegen (http://catb.org/jargon/html/N/nasal-demons.html) ließe.

-> Standardkonformen Code schreiben, dann bleibt einem sowas erspart. C und C++ beziehen einen nicht unerheblichen Anteil ihrer Geschwindigkeit genau daraus, dass der Compiler einfach immer davon ausgeht, dass bestimmte Sachen (Overflow, Nullpointer-Dereferenz, usw.) einfach nicht vorkommen können, weil das Programm sonst kein standardkonformer Code wäre. Sicherzustellen, dass das auch tatsächlich so ist, ist Aufgabe des Entwicklers.

Wer etwas mehr drüber lesen will:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

[(del)]

Das hat ich schon den ganze Morgen an irgendwas erinnert... Jetzt hab ich es. :cool:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

Das bedeutet jetzt aber nicht, daß -fwrapv eine C-unkonforme Compiler Option ist, oder? ;)

[mfq]

Das bedeutet jetzt aber nicht, daß -fwrapv eine C-unkonforme Compiler Option ist, oder? ;)Nein, natürlich nicht.

Mit -fwrapv garantiert der GCC eben ein Verhalten, dass der Standard undefiniert lässt. Undefiniertes Verhalten kann natürlich auch heißen, dass genau das passiert, was man erwartet. Problematisch daran ist halt, dass man bei Nutzung von sowas nicht mehr portabel ist, da ein C-Compiler eine solche Option nicht kennen muss. Viele tun das auch nicht. Clang z.B. kennt sie aber soweit ich weiß. Code, der sich auf das fwrapv-Verhalten verlässt ist jedenfalls kein korrektes C mehr.

Es ist ja aber auch eigentlich kein Problem, zu prüfen, bevor der Overflow auftritt und nicht erst hinterher. Fefes Argumente gegen die im Bugreport vorgeschlagenen Vorgehensweisen überzeugen mich überhaupt nicht. Da es in C schon immer falsch war, sich auf ein bestimmtes Verhalten beim Signed-Overflow zu verlassen, sehe ich da sowieso kein großes Problem. Abgesehen davon weiß doch jeder, dass das Schreiben sicherer Software in C nunmal ein wenig Aufmerksamkeit und einen gewissen Aufwand erfordert. ;)

[(del)]

Mich überzeugen sie teilweise schon. Es ist soweit klar, daß wie bei jeder anderen Diskussion irgendwannmal lawyers auftauchen (meine jetzt mehr die verlinkte Disku als den Thread hier bei uns) und behaupten, daß ist schon alles richtig wie es ist. In dem Fall language lawyers...

Es gibt immer Leute die Argumente dafür suchen, daß alles so wie es GERADE ist, richtig ist. Ungeachtet dessen, daß die Welt ständig im Wandel ist, was dauernd auch zur gelegentlichen Rückwärtsrollen führt ;) Ich bin mir auch garnicht sicher, ob das meist überhaupt etwas mit Fachwissen zu tun hat. Das hat für mich mehr mit der Entscheidung zur Gruppenzugehörigkeit etwas zu tun. Solche Leute haben für mich eher ein soziologisches Problem als eine technische Meinung.

Was explizit jetzt die Bugbesprechung da angeht, erfährt man schlicht, daß es Leistung bringen sollte, es aber keine bringt. Dafür aber Problemme, falls man meint einen kritischen Schnippel zu haben und vorab pauschal absichern will.
Man erfährt auch, daß es den Versuch schon einmal gab und er wurde vom anderen "maintainer" verworfen/zurückgerudert und vom folgenden wieder reingenommen. Die Alten Garden...

Das ist für mich so ein Paradebeispiel dafür, daß man nicht zwangsläufig immer alles machen muß was man machen darf. Soetwas macht die Welt nicht besser. Beim ICC und MSVC scheinen die Schlüsselpositionen nicht mit Leuten besetzt zu sein die an solchen soziologischen Gebrechen leiden. Die optimieren das nicht weg. Irgendjemand hat da mal erkannt, daß man nicht immer alles gleich automatisch richtig macht, wenn man nichts falsch macht. Manches kann man auch einfach sein lassen, wenn es OFFENSICHTLICH keinen Nutzen hat.
Der Knaller da war ja, daß es sogar schadet (wie bspw. bei SPEC).

[mfq]

Der Knaller da war ja, daß es sogar schadet (wie bspw. bei SPEC).Öhm nope, das haste wohl falschrum gelesen.Other people have demonstrated that -fwrapv slows down the well-known SPEC benchmark.Wenn man den Overflow also definiert, kostet das bei SPEC Leistung. Wundert mich nicht, weil der undefinierte Overflow zumindest theoretisch zahlreiche Optimierungen ermöglicht.

Triviales Beispiel:
int x,y;
...
y = x * 6 / 3;

Könnte der Compiler ganz einfach durch
y = 2 * x;
ersetzen. Das geht aber nicht mehr, wenn der Integer-Overflow als 2er-Komplement-Wraparound definiert ist, da dann eben auch was ganz anderes rauskommen könnte, wenn x eine sehr große Zahl ist.

Ja, triviales und wahrscheinlich nicht sehr praxisnahes Beispiel, ich weiß. ;)