Erste 64-bit-viren Man bin ich froh noch 32-Bit zu haben
#1
geschrieben 25. August 2004 - 13:11
Einen wichtigen Grund für die geringe Verbreitung des W64.Shruggle stellt zum einen die Tatsache dar, dass bisher nur AMD einen 64-Bit-Prozessor für den PC anbietet und auch die 64-Bit-Variante von Windows XP zwar verfügbar ist, aber als Beta noch in den Kinderschuhen steckt. Der Virus befällt ein 64-Bit-System, indem er nach der Ausführung auf diesem nach ausführbaren 64-Bit-Dateien sucht und sich an diese anheftet.
Symantec stuft W64.Shruggle demnach auf allen 3 Kategorien (Infektionsgefahr, Schaden, Verbreitung) als geringe Bedrohung ein.
Quelle
Anzeige
#2
geschrieben 25. August 2004 - 19:07
Ähmmm. Ich will ja nicht viel sagen - aber auf welcher Plattform gibt es mehr Viren ?
Und wenn Du mich fragst - wenn irgendwelche Leute Probleme hatten um mich herum - dann doch eher mit alten - längst klassifizierten - Viren.
Aber kein Schxxxx interessiert sich im Moment für 64-Bit Viren. Da müßtest Du Dich
mit der AMD64-Version von XP schon verdammt ungeschickt benehmen, um Dir das einzufangen.
Aber es gibt diese Leute wirklich. Wenn es 50.000 Möglichkeiten gibt etwas richtig zu haben - mache treffen garantiert zielsicher die 1 Variante, mit der es schiefläuft.
Dieser Beitrag wurde von Meltdown bearbeitet: 25. August 2004 - 19:54
#3
geschrieben 25. August 2004 - 19:36
Zitat (Meltdown: 25.08.2004, 20:07)
Ähmmm. Ich will ja nicht viel sagen - aber auf welcher Plattform gibt es mehr Viren ?
Aber kein Schxxxx interessiert sich im Moment für 64-Bit Viren. Da müßtest Du Dich
mit der AMD64-Version von XP schon verdammt ungeschickt benehmen, um Dir das einzufangen.
Aber es gibt diese Leute wirklich. Wenn es 50.000 Möglichkeiten etwas richtig zu haben - mache treffen garantiert zielsicher die 1 Variante, mit der es schiefläuft.
Aber das ist einer der wenigen Viren der noch im Umlauf ist, der nicht auf Windows XP 32 Bit lauft.
Da stimme ich dir zu.,
Dieser Beitrag wurde von Imperator bearbeitet: 25. August 2004 - 19:37
#4 _FF1980_
geschrieben 25. August 2004 - 19:44
In einem Punkt könntest du Recht haben: Das ist der erste 64-Bit Virus, der AMD-Systeme heimsuchen kann.
Dennoch: Warum sagst du, dass du froh wärst noch einen 32-Bitter zu haben? Ich denke mal, dass das Groß der Viren und Würmer immer noch für 32-Bit gecoded wird. Diese sind zwar auch auf dem Athlon64 ausführbar, doch auf einen Virus mehr oder weniger auf die gesamte Masse der Schädlinge gesehen kommt es nun wirklich nicht mehr an.
Dafür lassen sich dank NX-Bit nicht alle Schädlinge der 32-Bit-Schiene auf meinem Sys ausführen {sorry}
Dieser Beitrag wurde von Connect2004 bearbeitet: 25. August 2004 - 19:47
#5
geschrieben 25. August 2004 - 19:49
Zitat (Imperator: 25.08.2004, 20:36)
Da stimme ich dir zu.,
Was willst Du damit sagen ? Das Du jetzt wegen diesem einen Virus Angst vor 64-Bit-Systemen hast ? Nebenbei: ich könnte mir gut vorstellen, das AVK2004
selbst diesen Virus schon in den Definitionen aufführt. Und diese auch auf Partitionen finden würde - selbst wenn der Scanner auf einem 32-Bit System läuft.
Ansonsten gilt wohl: die Itanium-Systeme müssen momentan mehr Angst vor Viren haben als das AMD64-Windows.
Wie sieht es eigentlich mit diesem riesigen 32-Bit Virenstamm für Windows 9x/NT (32-Bit) aus ?
Wenn das System rein im 64-Bit Native-Mode laufen würde - wie sieht es da mit
der "Kompatibilität" dieser "alten" Viecher aus ? Die ausführbaren Varianten können - wenn überhaupt - doch auch nur im 32-Bit Mode laufen.
Aber eben nicht auf 64-Bit Systemen im Native-Mode. Von Makro-Viren u.ä. mal abgesehen...
Darüber habe ich nämlich schon mal öfters nachgedacht. Selbst wenn die 64-Bit Variante 32-Bit Software ausführen kann (und das kann sie ja):
Allein durch die doch nicht unerheblichen Systemänderungen wird doch so einiges mit diesem Windows-Update doch gleich mitentsorgt. Das dürfte doch eine nicht ganz unerheblich Zahl von Varianten sein, die damit Probleme kriegen würde...
- Oder sehe ich das falsch ? Bin ich in der Hinsicht zu naiv ?
Dieser Beitrag wurde von Meltdown bearbeitet: 25. August 2004 - 19:51
#6 _FF1980_
geschrieben 25. August 2004 - 19:56
Der AMD Athlon 64 hat 3 Modi.
x86 32-Bit only
x86-64 mixed
native 64 Bit
Im Regelfall läuft der Prozi ab Werk im Mixed-Mode, sodass er beides ausführen kann, jedoch wird beim OS-Start festgelegt, welchen Modus er nutzen soll. Reines 64 Bit ist bei Windows noch nicht möglich, da Teile der 64-Bit Betas noch in 32-Bit programmiert sind.
Unter Suse Linux 9.1 habe ich aber schon mal den reinen 64-Bit-Modus gefahren. Da kann er dann zeigen, welche Power drinsteckt. MP3's lassen sich mit geeignetem Encoder bis zu 4x schneller coden als im 32-Bit-Modus
#7
geschrieben 25. August 2004 - 20:06
Zitat (Connect2004: 25.08.2004, 20:56)
Das ist mir durchaus klar, das Du Dein System noch nicht nativ mit 64-Bit fährst (bzw. fahren kannst).
Geht momentan nicht anders. Aber die theoretische Frage steht doch im Raum:
Je mehr 64-Bit ins Spiel kommt - wie weit schaffen es 32-Bit Viren dann noch
dazwischenzufunken ?
Im Mixed-Mode geht das natürlich. Aber im 64-Bit Native-Mode ? Wie sieht die Situation dann aus ?
Nebenbei: Mixed Mode hin oder her. Allein das Update auf ein AMD64-Windows ist ein gewaltiger Schritt für ein Windows-System.
Und ich könnte mir gut vorstellen, das allein durch diese Systemänderungen etliches
an Malware NICHT mehr laufen wird. Das ist bei normalen Applikationen ja schon der
Fall - und die benutzen i.d.R. genormte Arbeitsweisen & Schnittstellen. (Ausnahmen bestätigen die Regel).
Viren dagegen versuchen des öfteren ja mal den Weg durch die Hintertür(en). Wenn da so einige "Schlösser" ausgetauscht werden, sollte da doch so einiges an dieser Hürde scheitern.
Das ist es was ich mich sagen wollte. Das die Malware-Coder da für "Updates" sorgen, ist mir schon klar. Aber das wird auch nur auf aktuellere Varianten
zutreffen.
#8 _FF1980_
geschrieben 25. August 2004 - 20:11
Selbst wenn der Automatismus nicht da wäre, wäre es möglich einen 64-Bit-Carrier zu verwenden, welcher die Tür für 32-Bit wieder offen stößt, da der Modus reine Softwaresache ist.
#9
geschrieben 25. August 2004 - 20:18
Zitat (Connect2004: 25.08.2004, 21:11)
Bleibt aber immer noch das MS-Systemupdate durch das das neue Windows.
MS schafft es ja nicht mal mit dem XP-SP2 Änderungen für eine ausreichende
Kompatibilität zu sorgen.
Für XP-User noch "schlimmer": sie wollen es anscheinend sogar genau so - und
eben nicht anders.
Ich möchte nicht wissen, wie das bei dem AMD64-Windows ablaufen wird.
Da bin ich wirklich gespannt. Hoffentlich werden dabei - wenn es schon notwendig ist -
dann auch alte Zöpfe mal rigoroser abgeschnitten.
In mancher Hinsicht ist das ewige Festhalten an alten Standards dann auch zu sehr hemmend. Es gibt immer noch so einiges im PC das noch aus den 80ern stammt.
Muss ja nicht sein. Da hat man bei so einigen Details zu lange mit dem Abschaffen
gewartet.
#10
geschrieben 25. August 2004 - 20:26
Connect2004 sagte:
Na, liebe Leute, wer erkennt hier jemanden der nicht verstanden hat was NX macht und was es nicht kann...
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
#11 _FF1980_
geschrieben 25. August 2004 - 20:30
@Rika: NX ist wohl bekannt. Doch leben einige Schädlinge vom Pufferüberlauf und der wird hierbei verhindert.
Dieser Beitrag wurde von Connect2004 bearbeitet: 25. August 2004 - 20:31
#12
geschrieben 25. August 2004 - 20:34
Es gibt einige Szenarien in denen das nicht hilft, es gibt das Szenrio daß einfach systemeigenen Code verwendet wird (z.B. die FormatC-Routine o.ä.), oder einfach daß Seznrio daß man üblichen Code oder Daten-Müll einschelust, woraufhin das Programm abstürzt (nennt sich DoS).
Vor Format-String-Exploits o.ä. schützt es nicht, vor Scripten schützt es nicht, und vor der generellen Ausführung von schädlichem Code schützt es absolut gar nix. Kein Schädling lebt vom einem Pufferüberlauf.
Dieser Beitrag wurde von Rika bearbeitet: 25. August 2004 - 20:34
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
#13
geschrieben 25. August 2004 - 20:40
Das soll ja durchaus so gehen. Aber wenn ich Entwickler wäre, würde ich das auch per BIOS steuerbar machen. Das also ein Athlon 64 sich auch auf pur NATIVE einstellen lässt. Ist das so schwierig gewesen, das die Entwickler daran nicht gedacht haben ?
Ein nicht angemeldetes Diskettenlaufwerk (im BIOS) kann ich ja auch nicht nachträglich aktivieren. Selbst wenn es ordnungsgemäss installiert und angeschlossen ist.
Bin ich der Einzigste dem diese Idee da in den Kopf kommt ? Selbst Intel hat beim P3 die Seriennummer per BIOS abschaltbar gemacht.
Manchmal nervt es schon...
Ich weiß ja das es im Moment noch nicht ohne 32-Bit geht - und das dieser Zustand noch etliche Jahr(zehnte?) so weiter geht. Aber schon aus Sicherheitsgründen hätte
ich dem ATHLON64-Prozessor das mitgegeben im Konzept.
Zumal: Sobald wir erstmal ein 64-Bit Windows-System haben, geht das große Aktualisieren los. Dann will jeder möglichst viele/wenn nicht alle Tools/Treiber/Applikationen auf 64-Bit fahren. Und eben nicht mehr auf 32-Bit.
Nur: diese Abnabelungsprozess wird dauern. Sehr lange wahrscheinlich.
Dieser Beitrag wurde von Meltdown bearbeitet: 25. August 2004 - 20:52
#14
geschrieben 25. August 2004 - 20:48
Zitat (Rika: 25.08.2004, 21:34)
Stimmt natürlich: Nur:
Auch systemeigener Code wie "Format C:" muß ja durch irgendetwas erstmal
mutwillig zur Ausführung gebracht werden. Und das kann ja dann nur durch eingeschleusten Code passiert sein. Drehen wir uns da nicht im Kreis ?
#15 _FF1980_
geschrieben 25. August 2004 - 20:52
Hardwaremäßig wäre das machbar, jedoch müsste das dann endgültig geschehen. Zum Zeitpunkt jetzt wäre das nicht anzuraten, da die meisten Applikationen noch 32-Bit sind. Aber in 3 bis 4 Jahren - so denke ich zumindest - wird man dazu übergehen, einen Hardware-Umschalter zu verwenden, weil dann der 32-Bit-Krempel zum alten Eisen gehört und 64-Bit sich entgültig überall durchgesetzt hat. Bei der Umstellung von 16 auf 32-Bit kam die endgültige Einstellung des vollen 16-Bit-Supports mit Windows XP auf Softwareebene und dem Athlon64 auf Hardwareebene. Zumindest ist es mir auf dem Athlon 64 nicht gelungen, ein DOS 6.2 mit Windows 3.11 von einer CD zu booten, wobei für den I/O eine RAM-DISK verwendet wird. Die Meldung(vom BIOS): Code not supported