OpenBSD Server in strcat's Hacking Contest

Hmm .. interessante Idee. Leider eigne ich mich denkbar schlecht als Hagg0r, ich bin schon froh, wenn ich einen ssh-Login gebacken bekomme. :)
 
Ihr sollt die b0x auch nicht h4x0rn, sondern einfach mal an Hand eines Beispiels sehen,
wie brutal sicher OpenBSD ist und es in den höchsten Tönen lobpreisen :)
 
Ich habe die Gelegenheit einfach mal genutzt, um mich auf einer OpenBSD-Box umzusehen. Ich kenne ja sonst nur NetBSD aus alten Tagen und FreeBSD aus aktueller Zeit.

Ich kann bei meinem haXX0r-Wissen jetzt allerdings nicht beurteilen, was an OpenBSD sicherer ist als an FreeBSD in der gleichen Konfiguration.
 
Ich bin im Hacker-Contest Team meiner UNI. Eine Box auf der nichts verwundbares läuft kann man natürlich auch nichts hacken. Wenn er die Konfiguration nicht total verhunzt hat, wird es keinen Sieger geben.
 
Die Hacker. Eine Contest werden wir selbst wahrscheinlich aber auch irgendwann ausrichten. Das Problem ist, das die Leute die den Contest ausrichten nicht teilnehmen dürfen, und auf Teilnahme will halt kaum jemand verzichten.
 
Strcat macht vermutlich da eher Löcher rein, die von der Dummheit/Faulheit der Anwender herrühren, als von vulnerabler Software. War beim letzten auch so.
 
Ich habe mir das mal angesehen und kann auf Anhieb nichts finden. Ich habe nach einer lücke im cron gesucht, habe aber so schnell nichts gefunden.
 
Ich erwarte das die User, die sich einloggen, das $HISTFILE der Shell
*NICHT* und die loeschen/aendern/..! Ich kann das zwar nicht
verhindern, aber sollte jemand die ~/.zsh_history wiederholt
loeschen, werde ich den Contest beenden!

Gibts unter OpenBSD kein {s,u}appnd flag?
 
menace schrieb:
Strcat macht vermutlich da eher Löcher rein, die von der Dummheit/Faulheit der Anwender herrühren, als von vulnerabler Software. War beim letzten auch so.

War so. Ist es aber nicht.

Maledictus schrieb:
ibts unter OpenBSD kein {s,u}appnd flag?
Doch; allerdings ist das "umgehen" der $HISTFILE ein Leichtes. Das faengt an beim Starten einer anderen Shell, setzen von anderen Variablen (i. e. HISTFILE), "sourcen" einer anderen Konfigurationsdatei, ..
Von daher hab ich einfach nur an die "Vernunft" appeliert, die $HISTFILE zu nutzen und unveraendert zu lassen.
 
Zurück
Oben