🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: de.comp.security
11 messages
11 total messages Started by Dirk Rode Tue, 07 Apr 1992 15:38
Bug oder Feature in Interactive UNIX
#3
Author: Dirk Rode
Date: Tue, 07 Apr 1992 15:38
48 lines
2579 bytes
Shalom,

 ich hoffe, ich verbreite hier ein nicht unbedingt allgemein bekanntes
Problem ueber das ich heute gestolpert bin. Ich sollte auf einem 386 Rechner
unter Interactive UNIX Software installieren. Leider war root durch ein
Passwort geschuetzt, sysadm jedoch nicht.

 Loggt man sich nun als sysadm ein, so wird automatisch ein Eingabe- und
Verwaltungsprogramm gestartet. Aus diesem Programm heraus sind im Prinzip alle
systemrelevanten Aufgaben durchzufuehren. Allerdings duerfen Kennungen mit
UID < 100 nicht bearbeitet werden.

 Wie komme ich jetzt an die root Kennung ran? Nur durch einen Umweg.
Zunaechst muss ich mir eine normale User-Kennung einrichten. Unter dieser
Kennung kann ich mich dann einloggen. Mit more /etc/passwd kann ich sehen,
das sysadm mit dem homedir /usr/admin und /bin/rsh gestartet wird. Das
Verwaltungsprogramm wird also aus einem Profile gestartet.

 Also logge ich mich unter meiner neu eingerichteten Kennung ein, und
mache dann ein su sysadm. Nun habe ich schon eine rsh mit root Berechtigung.
Es kann nun nicht mit cd /etc gearbeitet werden, aber vi /etc/shadow ist
moeglich. Dann kann das Passwort der root einfach entfernt werden, und 
schon bin ich als root im System.

 Fazit:

 Auch bei Grundeinrichtung eines Rechners unbedingt auf alle Logins ein
Passwort setzten oder - wie bei Interactive UNIX - im Shadow bzw. Passwortfile
den Passworteintrag aus-xxx-en. Denn nicht nur die Rumspielerei unter
sysadm kann aergerliche Schaeden einrichten, eine rsh ist in diesem Fall
der Systemsicherheit ueberhaupt nicht zutraeglich. 
 Daher koennte man m.E. doch von den Herstellern verlangen, das beim ersten 
Einloggen als root zwangslaeufig ein Passwort fuer alle Kennungen vergeben
werden muss. Dies ist beim Einloggen eines normalen Benutzers so
vorgesehen.


mfG Dirk

P.S.: Ich hoffe, ich habe Euch nicht mit bekannten Dingen gelangweilt :-))
 
-- 
*  Dipl.Inform. Dirk Rode * diro@edison.Phone.North.DE                 *
*  Zwischenahner Str. 64  *                                            *
*  2910 Howiek            * Tel: ????? ????  ask me if you want to know*
*   ... Ein ganzer Kerl ...                                            *
*                       ... Dank Chappi :-))                           *
Re: Bug oder Feature in Interactive UNIX
#4
Author: Matthias.Krippendorf
Date: Wed, 08 Apr 1992 09:05
31 lines
1811 bytes
diro@edison.phone.North.DE (Dirk Rode) writes:

Naja Dirk!

Schoen, dass Du eine der ueblichen Sicherheitsluecken in frisch installierten
Betriebssystemen gefunden hast. Es ist leider ueblich, dass System-Accounts
ungesichert ausgeliefert werden. 

Es ist auch durchaus sinnvoll, auf dieses hinzuweisen. Jedoch eine detailierte 
Beschreibung zum Einbruch in ein System zu liefern, ist ja wohl das daemlichste,
was ich unter Security-News-Gruppen gesehen habe.

Stell Dir nur mal den Sysadmin vor, der aus dem Urlaub wieder kommt, Dein 
posting liest und dann feststellt, dass der Weg tatsaechlich funktioniert. Es 
sind dann naemlich schon einige eingebrochen. DANK SOLCHEN LEUTEN WIE DIR!!!!

Superuser koennen nun einmal nicht immer als erste News lesen.

Beim naechsten Mal kannst Du uns News-Lesern erzaehlen, dass es eine Luecke
gibt. Den Weg erklaerst Du bitte nur CERT oder vergleichbaren!!


	Danke im voraus, Matthias

PS: CERT posted auch nur das und nicht wie!
-- 
****************************************************************************
Matthias Krippendorf      Inhouse: lmk@kepler
Wiefelstederstrasse 45    Internet: Matthias.Krippendorf@arbi.Informatik.
2903 Bad Zwischenahn                Uni-Oldenburg.DE
************   Anybody out there with a longer email address   *************
Sicherheit (war: Re: Bug oder Feature in Interactive UNIX)
#7
Author: Frank Simon
Date: Wed, 08 Apr 1992 16:40
88 lines
5706 bytes
Hallo Matthias & andere Interessierte,

Matthias.Krippendorf@arbi.informatik.uni-oldenburg.de (Matthias.Krippendorf) writes:
>Schoen, dass Du eine der ueblichen Sicherheitsluecken in frisch installierten
>Betriebssystemen gefunden hast. Es ist leider ueblich, dass System-Accounts
>ungesichert ausgeliefert werden. 
Es ist aber nicht ok, dass Sicherheit vorgekaukelt wird durch die Trennung
von root und sysadm (sysadm kann uid < 100 nicht aendern), aber das ganze
so dilletantisch gemacht wird, dass es ueberhaupt nur Pseudo-Sicherheit
bietet. Es geht hier mehr als nur darum, dass sysadm kein PW hat. Auf einen
SCO Unix (angeblich C2-styled) sieht es nicht anders aus. 

>Es ist auch durchaus sinnvoll, auf dieses hinzuweisen. Jedoch eine detailierte 
>Beschreibung zum Einbruch in ein System zu liefern, ist ja wohl das daemlichste
>was ich unter Security-News-Gruppen gesehen habe.
Irre gut. Irre gut pauschalisiert. Gefaellt dir das Gegenteil besser ?  Siehe
dir mal das NSA an. Die kannten z.B. den Bug von sendmail, der spaeter u.A.
zum Arpa-Internet-Wurm fuehrte schon seit 1,5 Jahren und hielten es nicht
fuer notwendig ein Ton zu sagen. Braucht ja keiner Wissen, um was sich die
NSA oder Dockmaster kuemmert. Und das ist nicht ein Einzelfall sondern
gaengige Praxis. Auch hier in Deutschland.

>Stell Dir nur mal den Sysadmin vor, der aus dem Urlaub wieder kommt, Dein 
>posting liest und dann feststellt, dass der Weg tatsaechlich funktioniert. Es 
>sind dann naemlich schon einige eingebrochen. DANK SOLCHEN LEUTEN WIE DIR!!!!
Sowas kommt vor. Und wenn ein SysAdmin dadurch Daten verliert, die fuer einen
Betrieb lebenswichtig waren, dann gehoeren die Entscheidungstraeger vor die 
Luft gesetzt, die eine Infrastruktur geschaffen haben, die eine solche Ab-
haengigkeit geschaffen hat.

Im IT-Sicherheitshandbuch, welches vom BSI rausgegeben wird, sind ja 
(Oh Wunder) auch 2 Kapitel ueber Technikfolgenabschaetzung und Risiko-
folgenabschaetzung drin. Wenn diese nicht beim Relegator rausgeflogen sind,
dann koennte das mal eine echte Bereicherung fuer jene sein, die glauben
technokratisch an Sicherheitsfragen rangehen zu koennen. 

Sicherheitstechnik muss sein, aber wer sie allein als Allheilmitteil ein-
setzt, der hat schon verloren. Wenn ein Sicherungsmechanismus davon lebt,
dass bestimmte Arbeitsweisen nicht verraten werden, dann ist es ein 
Unsicherungsmechanismus per definition.

Rechner KOENNEN nicht sicher sein. Das ist unmoeglich. Du kannst nur versuchen 
die Wahrscheinlichkeit fuer ein Eindringen zu reduzieren. Die Computer sind 
von ihrem Konzept eher Maschinen zur Verarbeitung von Informationen. Von Natur 
aus, sind sie offen. Es gibt keine perfekten Programme und daher gibt es keine 
perfekten Sicherungsmassnahmen die dieser Natur entgegenwirken.

>Superuser koennen nun einmal nicht immer als erste News lesen.
Hah. Weisst du wieviel Rechner es in der Welt gibt ?   Weisst du wieviel
davon News lesen ?  Tausende von Rechner sind vermutlich heute noch 
mit uralten Sicherheitsloeckern angreifbar. Und ein "Cracks" kann allein
schon aus der Warnung recht gut vermuten, welches Sicherheitsloch wohl 
zu dieser Warnung gefuehrt hat. Aber die "echten" Hacker werden sowas 
nicht ausnutzen und keine Daten zerstoeren. Und glaubst du Wirtschafts-
kriminelle mit der Tatwaffe "Computer" auch nur paar Sekunden mit einer
zurueckhaltenden Informationspolitik aufzuhalten ???

>Beim naechsten Mal kannst Du uns News-Lesern erzaehlen, dass es eine Luecke
>gibt. Den Weg erklaerst Du bitte nur CERT oder vergleichbaren!!
Ich wuerde nicht auf CERT schwoeren. In Deutschland werden naemlich die
Informationen, die ueberhaupt ermoeglichen diese Sicherheitsluecken in ihrer
ganzen Bandbreite nachzuvollziehen nur 4 (!) Institutionen gegeben. In
Deutschland kriegen wir immer noch Informationen aus USA, weil fuer den
Bereich "Rechnersicherheit" kein deutsches CERT existiert. 

Fakt ist: Rechner mit schueztenswerten Daten gehoeren nicht vernetzt. Wer
	  das tut begeht grobe Fahrlaessigkeit. Bei Versicherungen sind
	  Risikoabschaetzungen nix neues. Falls sich jemand abhaengig von
	  einen Rechner machen will, dann soll er - verdammt nochmal - das
	  auch machen. Methoden dafuer gibt es. 

Die Methode, wie sie z.B. auch CORA (Europaeische Vereinigung gegen Viren)
anwendet hilft nicht weiter. Die sagen auch, dass sie mit niemanden zusammen-
arbeiten, der Informationen ueber Viren veroeffentlicht. Ralf Burger ist da
beliebte Zielscheibe. 

Wie mensch mit Sicherheitsloechern umgeht ist heutzutage eben noch nicht
geklaert und wer nach NSA-Methode, CERT-Methode oder Free-flow-of-Information
vorgeht, muss sich ueber die Vor- und Nachteile im klaren sein. Ulimative
Loesungen gibt es eben nicht.

Terra
-- 
-------------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG     !
!  terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206   !
!	       "Gelesen, Gemerkt, Vergessen" (Joerg Lehners)                  !
-------------------------------------------------------------------------------
Re: Bug oder Feature in Interactive UNIX
#8
Author: Dirk Rode
Date: Thu, 09 Apr 1992 17:12
25 lines
1558 bytes
Shalom,

 Fakt war, das Du mir einen Rechner mit gesetztem Root PW uebergeben
hast, und nicht einmal mehr das root PW-wusstest, das Du gesetzt hattest,
damit keiner in den Rechner ueber Netz einbrechen kann. Da musste ich 
gezwungenermassen hacken. Und nicht einmal Du hast diesen "Bug" gekannt,
obwohl Du als Systemadministrator in einem Netzlabor arbeitest.

 Ausserdem gehoeren diese UNIX ausgestatteten Telespielconsolen hoechstens
in ein Kinderzimmer und nicht an ein Netzwerk wie Internet. Zumindest dann 
nicht, wenn der Administrator absolut keine Ahnung (damit bist Du nicht 
gemeint - Du hast Ahnung) von Sicherheit hat.

 Warst Du vielleicht noch nicht ganz wach, als Du Dein Followup
geschrieben hast? Anders ist Dein etwas unverschaemter Ton doch wohl nicht
zu erklaeren.

mfG Dirk

-- 
*  Dipl.Inform. Dirk Rode * diro@edison.Phone.North.DE                 *
*  Zwischenahner Str. 64  *                                            *
*  2910 Howiek            * Tel: ????? ????  ask me if you want to know*
*   ... Ein ganzer Kerl ...                                            *
*                       ... Dank Chappi :-))                           *
Re: Sicherheit (war: Re: Bug oder Feature in Interactive UNIX)
#9
Author: Dirk Rode
Date: Thu, 09 Apr 1992 17:12
12 lines
828 bytes
Shalom,

 volle Zustimmung.

mfG Dirk

-- 
*  Dipl.Inform. Dirk Rode * diro@edison.Phone.North.DE                 *
*  Zwischenahner Str. 64  *                                            *
*  2910 Howiek            * Tel: ????? ????  ask me if you want to know*
*   ... Ein ganzer Kerl ...                                            *
*                       ... Dank Chappi :-))                           *
Re: Bug oder Feature in Interactive UNIX
#13
Author: Patrick Wendt
Date: Fri, 10 Apr 1992 10:28
29 lines
2064 bytes
Matthias.Krippendorf@arbi.informatik.uni-oldenburg.de (Matthias.Krippendorf) writes:

>Stell Dir nur mal den Sysadmin vor, der aus dem Urlaub wieder kommt, Dein 
>posting liest und dann feststellt, dass der Weg tatsaechlich funktioniert. Es 
>sind dann naemlich schon einige eingebrochen. DANK SOLCHEN LEUTEN WIE DIR!!!!

Aeh, also, wenn ein Systemverwalter einen sysadm-Account ungeschuetzt
laesst, dann verdient er es, dass seine Platte formatiert ist, wenn
er aus dem Urlaub wiederkommt.  -  Es ist doch Tatsache, dass man
solche Accounts (und eigentlich alle Accounts) nicht ohne Password
laesst; wer das tut, sollte sich einen anderen Job suchen.

Daher weiss ich auch nicht, warum das, was Dirk gepostet hat, hier
nicht hergehoert, denn es sagt nur dass, was jedem SysAdm bekannt
sein sollte ... und es verdeutlicht, wie wichtig es ist, sich nicht
auf vorgetaeuschte Sicherheit eines Systems zu verlassen. Es gibt keine
absolute Sicherheit in RechnerSystemen, es sei denn, man schaltet sie aus :-)

Gruss ... Pat !

-- 

--
 ----------------------------------------------------------------------------
 -  Patrick Wendt  |   root@chamber.in-berlin.de |  Zombies Burial Chamber  -
 - Chamber-Systems |   root@megiddo.in-berlin.de | Public UNIX Sys-V 386/33 -
 - - - - - - - - - | pwendt@opal.cs.tu-berlin.de | Data: +49 30 / 402 56 92 -
 - Berlin, Germany | pwendt@bitcave.in-berlin.de | HST D.S. 14400bps V32bis - 
 ----------------------------------------------------------------------------
Re: Bug oder Feature in Interactive UNIX
#14
Author: Thomas Liening
Date: Fri, 10 Apr 1992 16:21
40 lines
2727 bytes
Hallo,

Matthias.Krippendorf@arbi.informatik.uni-oldenburg.de (Matthias.Krippendorf) writes:

[...]
>Es ist auch durchaus sinnvoll, auf dieses hinzuweisen. Jedoch eine detailierte 
>Beschreibung zum Einbruch in ein System zu liefern, ist ja wohl das daemlichste,
>was ich unter Security-News-Gruppen gesehen habe.

>Stell Dir nur mal den Sysadmin vor, der aus dem Urlaub wieder kommt, Dein 
>posting liest und dann feststellt, dass der Weg tatsaechlich funktioniert. Es 
>sind dann naemlich schon einige eingebrochen. DANK SOLCHEN LEUTEN WIE DIR!!!!

Dies ist die eine und sicherlich wichtigere Seite der Medaille. Ich hatte
aber auch schon mal einen Fall, bei dem mich exakt ein solcher Bug davor
bewahrt hat, auf meinem System eine komplette Neueinrichtung eines ISC-
Systems - verbunden mit erheblichen Datenverlusten - durchfuehren zu muessen.
Dabei hatte ich als root mit "vi /etc/passwd" eine andere Shell fuer den
root-Account eingetragen, die allerdings tatsaechlich gar nicht mehr auf
der Platte vorhanden war. Unmittelbar danach hatte ich das System herunter-
gefahren und konnte mich nach dem naechsten Reboot nicht mehr als root
einloggen. Nur durch Ausnutzung einer Sicherheitsluecke gelang es mir,
wieder als Superuser in die Kiste reinzukommen.
Deswegen finde ich es _als Betreiber eines niemandem ausser mir zugaeng-
lichen Unix-Systems_ sehr praktisch, wenn man Kenntnis auch ueber das
zum Einbruch noetige Verfahren bekommt. Allgemein gesehen ist es nichts-
destotrotz unverantwortlich ... nur wie sollte man sicherstellen, dass 
nur "berechtigte" Sysadmins die entsprechenden Informationen erhalten?
Denn andererseits: Was nutzt es mir, wenn ich den Weg nur Sicherheits-
organisationen erklaere, die dann vielleicht irgendwann mal den Hersteller
des Systems informieren, der seinerseits eventuell irgendwann vielleicht
einen Bugfix dafuer erstellt? 

Gruss, Thomas.

-----------------------------------------------------------------------
Thomas Liening * Roennebergstrasse 14 * 1000 Berlin 41, Germany, Europe 
Voice: +49 30 852 59 28 * Fax: +49 30 852 59 28 (call voice prior!)
Smart: root@chshost.in-berlin.de
Bang: ...mcsun!unido!fub!einoed!bitcave!chshost!root
Re: Bug oder Feature in Interactive UNIX
#12
Author: Dirk Rode
Date: Sun, 12 Apr 1992 16:58
45 lines
2845 bytes
Shalom,

 auch wenn es nicht direkt hier hergehoert:

 - 1.) Das Followup von M. Krippendorf war ein persoenlicher Schuss
       gegen mich, auf den ich entsprechend reagiert habe. Das mir mein
       Artikel dann in mehreren private Mails gequotet zugeschickt wurde
       freut hoechstens die Telekom und koennte von meiner Seite aus zu
       einer Wiederholung der Diskussion ueber das Quoten von Artikeln
       fuehren

 - 2.) bin ich mit Frank Simon und auch weiteren einer Meinung, das einige
       sicherheitsrelevante Themen nur durch explizite Beschreibung zu
       beheben sind. Sonst kommen die Infos nicht rueber. Ich haette
       natuerlich auch nur Problem mit Sysadm oder Sicherheitsloch auf 
       Interactive schreiben koennen. Und nur ausgewiesene Sysops die Infos
       per schriftlicher Anfrage per Vorkasse per Einschreiben mit 
       Rueckschein wieder zusenden koennen. Doch das ist eine Forderung
       nach Orange Book Klassifizierung A. Also bei Interactive Spielerechnern
       voellig ueberzogen. 

 - 3.) Wir sind uns doch wohl alle einig, das UNIX derzeit nichtmal C2
       erreicht. Damit ist es ehh unsicher. Und nur durch direkte Warnung
       koennen derart bittere Fehler die durch die implizierte Sicherheit
       eines Systemes erzeugt werden, behoben werden. Meine erste Aktion
       ist bei einer Installation alle Logins in /etc/passwd bzw. /etc/shadow
       (ausser root) die nicht mit einem Passwort versehen sind, mit * oder
       *LOCK* oder NONE im PW Feld zu sperren.

 - 4.) Ein Hinweis: Auf vielen Rechnern ist das NFS ein Sicherheitsloch.
       Das werde ich hier mal nicht beschreiben, ihr wisst jetzt sicher alle,
       worum es bei diesem Loch geht. CERT hat eine entsprechende Warnung 
       Mitte 1991 rausgegeben, die war detaillierter :-))) Aber der "BUG"
       ist bei vielen Systemen noch drin. Damit kann man in ca 20 Minuten
       root werden und innerhalb von 2 Minuten /etc/passwd und /etc/hosts etc
       kopieren. Trivial.

mfG Dirk

-- 
*  Dipl.Inform. Dirk Rode * diro@edison.Phone.North.DE                     *
*  Zwischenahner Str. 64  * D-W-2910 Howiek                                *
*   Fuer Veroeffentlichungen _AUSSERHALB_ des Newssystemes gelten _MEINE_  *
*  Geschaeftsbedingungen. Nichtbeachtung wird in der Regel zivil- und      *
*  strafrechtliche Folgen nach sich ziehen.       gez. Dirk Rode           *
Re: Bug oder Feature in Interactive UNIX
#15
Author: Joern Lubkoll
Date: Tue, 14 Apr 1992 22:17
19 lines
1270 bytes
root@chshost.in-berlin.de (Thomas Liening) writes:

>Dabei hatte ich als root mit "vi /etc/passwd" eine andere Shell fuer den
>root-Account eingetragen, die allerdings tatsaechlich gar nicht mehr auf
>der Platte vorhanden war. Unmittelbar danach hatte ich das System herunter-
>gefahren und konnte mich nach dem naechsten Reboot nicht mehr als root
>einloggen. Nur durch Ausnutzung einer Sicherheitsluecke gelang es mir,
>wieder als Superuser in die Kiste reinzukommen.

runterfahren - (oder ausschalten) - DiskEditor rein und passwd-file suchen,
dann einfach direkt auffer Platte editieren. Geht ohne Probleme. Oder im
installierten Kernel-Debugger die Uids des Prozesses aendern (is schon
recht aetzend).

jl


-- 
Joern Lubkoll, lumpi@dobag.in-berlin.de, *-> NeXTMail _unerwuenscht_ <-*
Re: Bug oder Feature in Interactive UNIX
#18
Author: Dirk Rode
Date: Wed, 15 Apr 1992 17:24
36 lines
2170 bytes
Shalom,

lumpi@dobag.in-berlin.de (Joern Lubkoll) writes:

>runterfahren - (oder ausschalten) - DiskEditor rein und passwd-file suchen,
>dann einfach direkt auffer Platte editieren. Geht ohne Probleme. Oder im
>installierten Kernel-Debugger die Uids des Prozesses aendern (is schon
>recht aetzend).

 spielst Du damit auf diese boese Interactive Macke an? Die soll aber gefixed
sein. Somit scheidet m.E. die Kernel-Debugger Methode fuer UID!=0 aus.

 Ok, auf Hardware Seite kann man (fast) alles machen. Manchmal wirds einem
da echt einfach gemacht (wie bei SUN). Die urspruengliche Geschichte ist 
- und das war die eigentliche Gefahr - im Prinzip primiv ueber das Netz
machen. Zumal per default in 

/etc/default/login zwar console fuer root login vorgegeben ist, aber in
/etc/default/su    eben mit #console ein su von ueberall her moeglich ist.

 Das ist schon bitter. Zumindest, wenn man das nicht weiss. Und an dieser
Stelle sucht man garantiert zuletzt, da die Dateien in /etc/default 
unuebersichtlich sind (wer ahnt, das der simple Hinweis auf Console 
sich mit der Zulassung des RootLogins befasst). Ich habe das Zeugs auch
erst gefunden als ich mich mit dem ulimit angelegt habe und es veraendern
wollte. Das steht naemlich auch in /etc/default/login.


mfG Dirk

-- 
*  Dipl.Inform. Dirk Rode - Zwischenahner Str. 64 - D-W-2910 Howiek        *
*  OFFIS - Rechnerbetrieb   E-Mail: diro@edison.phone.North.DE             *
*   Fuer Veroeffentlichungen _AUSSERHALB_ des Newssystemes gelten _MEINE_  *
*  Geschaeftsbedingungen. Nichtbeachtung wird in der Regel zivil- und      *
*  strafrechtliche Folgen nach sich ziehen.       gez. Dirk Rode           *
Re: Bug oder Feature in Interactive UNIX
#19
Author: Joern Lubkoll
Date: Thu, 16 Apr 1992 22:46
28 lines
1607 bytes
diro@edison.phone.North.DE (Dirk Rode) writes:
>lumpi@dobag.in-berlin.de (Joern Lubkoll) writes:

>>runterfahren - (oder ausschalten) - DiskEditor rein und passwd-file suchen,
>>dann einfach direkt auffer Platte editieren. Geht ohne Probleme. Oder im
>>installierten Kernel-Debugger die Uids des Prozesses aendern (is schon
>>recht aetzend).

> spielst Du damit auf diese boese Interactive Macke an? Die soll aber gefixed
>sein. Somit scheidet m.E. die Kernel-Debugger Methode fuer UID!=0 aus.

Mit dem Kernel Debugger darfst du alles - erstes Gesetz :-)
Und meinen alten schoenen Security Bug haben sie doch wirklich gefixed,
muss man ihnen lassen - hat ja auch lange genug gedauert (d.h. nach dem
Posting ging es sehr schnell :-))

> Ok, auf Hardware Seite kann man (fast) alles machen. Manchmal wirds einem
>da echt einfach gemacht (wie bei SUN). Die urspruengliche Geschichte ist 

naja, eeproms koennen ja auch passwords haben.

jl


-- 
Joern Lubkoll, lumpi@dobag.in-berlin.de, 	| Gib  EMMA |
*-> NeXTMail _unerwuenscht_ <-*			| K E I N E |
						|  CHANCE   |
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads