Nach Bash-Installation ausgesperrt

[user123]

Guten Morgen,

mir ist soeben etwas ganz Blödes passiert! Habe mir per ipkg die Bash nachinstalliert und wollte grade diese für den Benutzer root aktivieren und dementsprechend in der /etc/passwd den Pfad der Shell von root geändert.

Tja, nur leider hab ich nicht richtig geschalten und einfach den falschen Pfad eingetragen. Anstelle von /opt/bin/bash steht jetzt /bin/bash in der Zeile, kurz gesagt ich hab mich ausgesperrt.

Mit dem Benutzer admin komme ich per SSH und Telnet zwar auf die Diskstation aber kann ohne root-Rechte die passwd nicht ändern oder einen passenden Symlink anlegen.

Hat jemand ne Idee wie ich wieder auf die Box komme? Durch einen Reset (http://www.synology.com/support/faq_show.php?lang=deu&q_id=127) wird die passwd nicht wieder hergestellt oder?

 

[user123]

Konnte mein Problem selber lösen

Da ich mich nur als admin über Telnet anmelden konnte aber keine root-Rechte hatte habe ich zumindest nach einem Weg gesucht die passwd beschreibbar zu machen. Zum Glück darf man die /etc/rc.network als non-root bearbeiten denn darin habe ich eine Zeile hinterlegt die mir die passwd per chmod auf 666 setzt. Danach habe ich die Diskstation neu durchstarten lassen und konnte anschließend als admin die passwd berichtigen.

 

[jahlives]

Zum Glück darf man die /etc/rc.network als non-root bearbeiten denn darin habe ich eine Zeile hinterlegt die mir die passwd per chmod auf 666 setzt.

@all Linux Kenner
Ist das nicht eine ziemliche Sicherheitslücke? Da kann man ja die Rechte von nahezu aller Dateien als non-root ändern

 

[user123]

Nicht falsch verstehen, "normale" Benutzer können sich ja gar nicht per Konsole auf die Diskstation verbinden. In der passwd wurde ihnen /bin/csh als Login-Shell hinterlegt welche gar nicht existiert. Der Login wird dann einfach abgewiesen, genauso wie es oben vorhin bei meinem root-Benutzer war.

Der admin könnte sich anmelden und wie schon erwähnt die rc.network ändern und diverse Dinge hinterlegen um so an root-Rechte zu gelangen aber selbst da ist ja erstmal das Admin-Kennwort notwendig.

 

[jahlives]

Und ein "normaler" User, der sich einloggen darf, kann diese Datei nicht beschreiben?

 

[user123]

Probiere es aus, ein normaler Benutzer kann sich nicht per SSH & Telnet anmelden und kommt somit auch nicht zu dieser Datei um sie zu modifizieren.

Genauso wenig klappt das über die Filestation - die Systemordner sind dort nicht zu erreichen.

 

[jahlives]

Probiere es aus, ein normaler Benutzer kann sich nicht per SSH & Telnet anmelden und kommt somit auch nicht zu dieser Datei um sie zu modifizieren.

Darum die Frage ob ein normaler User, der sich anmelden darf, diese Datei auch ändern kann. Klar solange keine gültige Shell in passwd steht kann man sich ned anmelden, aber was ist wenn eine drin steht? Kann dieser User diese Datei beschreiben? Ich probier das mal heute abend nach der Arbeit aus...

 

[user123]

Sollte eine gültige Shell hinterlegt sein und somit ein Login möglich ist dann kann ein Benutzer natürlich die Datei bearbeiten. Die rc.network hatte auf meiner Diskstation 777-Rechte und ich selber hatte die noch nie angerührt.

 

[itari]

Hat jemand ne Idee wie ich wieder auf die Box komme?

Du kannst auch für eine solche Aufgabe das AdminTool verwenden. Installiert bekommst es, solange der DS-Manager noch läuft ... und dann hast halt die Recht des sys-Apache, welcher ja unter 'root' läuft.

Die Diskussion mit dem telnet/ssh-Login ist müßig, solange man als Systemverwalter die Datei /etc/passwd im Auge behält und dort keine Türchen öffnet; also immer schön drauf achten, dass das Start-Shell-Feld auf '/sbin/nologin' steht.

Itari

 

[thedude]

Das stimmt:

ds209> ls -al /etc/rc.network
-rwxrwxrwx    1 root     root         6647 Aug 18  2009 /etc/rc.network

Das oben beschriebene ist also für jeden user möglich, der shell access hat. Wie seht das denn mit dem restarten aus? Kann der jeder non root user remote machen? Physikalisch an der Box zählt ja nicht.

gruss
dude

 

[user123]

Also in meinem Fall war der Reboot über den Webmanager kein Problem. Der Benutzer admin hat ja wie itari schon erwähnte durch den Apache root-Rechte und ermöglicht das Neustarten.

Aber auch hier wird ja genauso das Kennwort benötigt wie beim SSH-Login.

 

[itari]

Wer thematisiert das 'Sicherheitsloch' denn mal bei den Synology-Entwicklern. Es wäre ja für die recht einfach, den Dateien das Schreibrecht wegzunehmen, und das in der nächsten Firmware-Version dann für alle zur Verfügung zu stellen.

Itari

 

[jahlives]

Ich melde das mal an Synology (wenn es der TS nicht bereits gemacht hat)

 

[user123]

Ich melde das mal an Synology (wenn es der TS nicht bereits gemacht hat)

Ja kannst Du gerne tun - ich hab es noch nicht gemacht.

 

[jahlives]

Meldung an Syno ist raus. Mal gucken was die dazu meinen

 

[jahlives]

Synology scheint am Sonntag zu arbeiten! Heute die folgende Antwort bekommen

Dear Tobi,

Thanks for your message.

Thank you for bringing this suggestion to our attention. It sounds like a
great idea. I will make sure to pass this idea to our product development
team for consideration.

Thanks again for your message and your interest in Synology. Feel free to
contact us for any further assistance.

Best Regards,
Antoine Yang

On Fri, Mar 26, 2010 at 8:20 PM, wrote:

> Dear Synology
>
> today we had a case in our forum where we think that the issue could be a
> security hole. It's concerning the file /etc/rc.network. The file has
> world-wide write rights on it
>
> -rwxrwxrwx 1 root root 6647 Aug 18 2009 /etc/rc.network
>
> So it's possible for any user with Shell access to put a line like chmod
> 0777 /etc/passwd and restart the box. After the restart full write access is
> granted for any user on this file. Even the webserver user nobody could
> perform this trick to change the right(s) on any file accessible.
> Would it be possible to remove the write access on rc.network for anyone
> except root and admin? That should solve this problem
>
> Best regards
>
> tobi
>
​

 

[jahlives]

Ich habe bei mir mal folgendes als Fix gemacht

find / -type f -user 0 -perm 0777 | grep -v volume1 | grep -v proc | xargs chmod 0755 "{}";

scheint alle solchen Files zu erwischen

p.s. setzt ipkg findutils voraus

 

[itari]

Wie viele Dateien sind denn betroffen?

Itari

 

[jahlives]

/var/spool/thumb_create.queue
/var/spool/thumb_create.queue.tmp
/etc/rc.network
/etc/portforward/routerdb_version
/etc.defaults/rc.network
/etc.defaults/portforward/routerdb_version
/usr/syno/bin/curl
/usr/syno/bin/synopftest
/usr/syno/bin/synoportforward

+ die Bilder der Photostation, welche ebenfalls root gehören und mit weltweiten Schreibrechten versehen versehen sind

 

[itari]

Das ist jetzt aber überschaubar ... eigentlich sind nur die /etc-files ein Problem. Der Rest wird ja nicht als Skript ausgeführt und ob hier jemand wirklich einen Hack ins curl bauen kann, bezweifle ich grad.

Itari