Root passwd zichtbaar bij gebruik van sudo over ssh

[Arioch]

Hoi tweakers,

Ik ben op een vreemde bug gestoten, namelijk dat mijn password zichtbaar is voor iedereen die over mijn schouders meekijkt, indien ik het volgende doe:

code:

arioch@server ~ $ ssh arioch@192.168.0.1 sudo tail -f /var/log/messages; exit
Password: **********
Password: help_dit_passwd_is_zichtbaar

-tail output-

Kan ik dit zelf oplossen zonder in de source te duiken? Op zich lijkt me dit toch niet zo'n vreemd commando.
Om het veiliger te maken had ik een exit achter het commando gezet, zodat er netjes uitgelogd wordt indien iemand op ctrl-c zou duwen. Maar aangezien mijn passwd gewoon zichtbaar is maakt het niet veel uit...

Versies:
Sudo version 1.6.8p9
OpenSSH_4.2p1, OpenSSL 0.9.7e 25 Oct 2004

[ Voor 9% gewijzigd door Arioch op 09-11-2005 18:52 . Reden: versies toegevoegd ]

[CyBeR]

beter zorg je op je andere doos gewoon dat user arioch die file mag lezen.

Dit is waarschijn trouwens een probleem met je $TERM.

[Wolfboy]

In navolging op CyBeR, je kunt ook voor dit specifieke commando wat toevoegen aan /etc/sudoers zodat de gebruiker er geen wachtwoord voor hoeft op te geven.

[Wilke]

Mja, maar dat is het symptoom bestrijden en niet het probleem.

Natuurlijk hoort dit niet, maar weet iemand waar je zoal naar moet kijken om te zien waar het aan ligt? Ik heb zoiets als dit nog niet eerder gezien.

[Wolfboy]

Ik heb het net eventjes getest en onder FreeBSD en onder Linux gebeurd het.

Het is een probleem met de commando modus van OpenSSH, als ik /bin/sh als commando invoer dan merk ik ook dat er niets gemaskeerd wordt daarna.

edit:
Er is overigens ook wel wat voor te zeggen waarom het zo zou horen.
Aangezien de commando's eigenlijk geen input horen te krijgen (op de argumenten na) is het niet vreemd dat hier niet op gelet wordt, maar toch hoort het niet.

[ Voor 36% gewijzigd door Wolfboy op 09-11-2005 19:40 ]

[Arioch]

Bedankt voor de reacties, en vooral Wolfboy om het even verder uit te pluizen.
Ik denk dat ik het ga oplossen door de gebruiker leesrechten te geven op de logfile of eventueel via sudo. Een nette oplossing is het niet echt... maar toch liever dit dan dat mijn passwd zichtbaar is voor buitenstaanders.

[ Voor 20% gewijzigd door Arioch op 09-11-2005 20:14 ]

[irondog]

Wolfboy schreef op woensdag 09 november 2005 @ 19:38:

edit:
Er is overigens ook wel wat voor te zeggen waarom het zo zou horen.
Aangezien de commando's eigenlijk geen input horen te krijgen (op de argumenten na) is het niet vreemd dat hier niet op gelet wordt, maar toch hoort het niet.

Je hebt helemaal gelijk. Het commando dat uitgevoerd wordt door ssh, wordt niet op een TTY uitgevoerd.

Het is een bug in sudo. Deze zou namelijk moeten checken of dit het geval is of niet. Als deze bug is opgelost is het resultaat dat sudo dienst weigert i.p.v. je password weergeven bij het intypen.

Ofwel: Dit ga je niet zonder initiële root login werkend krijgen.

[Wolfboy]

@irondog: je hebt gelijk ja, je krijgt idd geen TTY, ik heb het net eventjes getest en su weigert dan ook dienst.

Mjah, de vraag is ook of sudo uberhaupt wel moet controleren of je een TTY hebt, ik vind het meer de verantwoordelijkheid van de gebruiker eigenlijk

[Gerco]

Lijkt me dat sudo niet moet checken of er een TTY is (al dan niet virtueel). Hoe moeten anders geautomatiseerde processen sommige commands als root uitvoeren?

Misschien wil ik wel dat een user in een cronjob 1 commando als root kan uitvoeren, dan ga ik natuurlijk niet de hele binary suid maken, dan geef ik die user sudo rechten voor dat ene command. Dat zou dan dus niet meer kunnen.

Voorbeeld:
Een www-statistieken verzamel programma, misschien wil ik die wel het recht geven om de webserver te restarten ofzo, hoe zou je dat doen zonder sudo

[ Voor 18% gewijzigd door Gerco op 09-11-2005 23:53 ]

[daft_dutch]

wie gaat er nu sudo rechten aan tail verlenen dan ben je toch niet goed bij je hoofd.

[Wolfboy]

Je denkt iets te simpel daft_dutch, niemand zegt dat je heel tail sudo rechten moet geven.
Wat dacht je van een regeltje als deze?

username  localhost=/bin/tail -f /var/log/messages

Dan is het wel redelijk veilig

[pierre-oord]

Je kan in het bestand sudoers ook opgeven dat een bepaalde gebruiker een commando mag uitvoeren als een "bepaalde" gebruiker (root bijvoorbeeld).

man sudoers

Ik gebruik dat vaak, is wel veiliger dan je password in een automatisch scriptje zetten ofzo...

[wzzrd]

Heeft iemand die dit heeft ervaren dit al gemeld in de bugzilla o.i.d. van het betreffende programma? Lijkt me wel op zijn plaats...

[Arioch]

Het wordt zo dadelijk gesubmit.
Bedankt voor de reminder, ik was van plan het te submitten maar ben het dan uiteindelijk vergeten te doen.

[CyBeR]

wzzrd schreef op vrijdag 11 november 2005 @ 15:51:
Heeft iemand die dit heeft ervaren dit al gemeld in de bugzilla o.i.d. van het betreffende programma? Lijkt me wel op zijn plaats...

Hoezo? Dit is geen bug in sudo hoor, maar fout gebruik van de gebruiker.

Dat je met een pistool in je voet kan schieten is geen bug in het pistool, maar een fout van de gebruiker van het pistool.

[Arioch]

Wolfboy schreef op woensdag 09 november 2005 @ 19:38:
Er is overigens ook wel wat voor te zeggen waarom het zo zou horen.
Aangezien de commando's eigenlijk geen input horen te krijgen (op de argumenten na) is het niet vreemd dat hier niet op gelet wordt, maar toch hoort het niet.[/edit]

Het probleem ligt dus niet bij sudo maar bij openssh.
Volgens mij is dit toch wel een bugreport waard.

[Garyu]

CyBeR schreef op vrijdag 11 november 2005 @ 16:15:
[...]


Hoezo? Dit is geen bug in sudo hoor, maar fout gebruik van de gebruiker.

Dat je met een pistool in je voet kan schieten is geen bug in het pistool, maar een fout van de gebruiker van het pistool.

Tsja, het is maar net hoe je het ziet blijkbaar. Dat je met een pistool in je voet kan schieten is eigenlijk gewoon een bug in het pistool. Het zou moeten bedenken dat dat niet zo hoort en dus niet schieten. Of een waarschuwing geven in de trant van "You're about to shoot yourself in the foot. Do you want to continue? Y/N". Helaas zijn pistolen niet geavanceerd genoeg en gebeuren er jaarlijks tientallen ongelukken met mensen die zichzelf per ongeluk in hun voet schieten.

Een programma hoort potentieel gevaarlijke situaties gewoon te herkennen en aan te geven dat de situatie potentieel onveilig is. Vervolgens is het aan de gebruiker om daar wat mee te doen of niet, maar in dit geval kan je het nauwelijks géén bug noemen. Dat password hoort gewoon niet te verschijnen. Of dat dan een bug is in sudo, openssh of whatever is minder relevant: het is en blijft een bug.

[Gerco]

Garyu schreef op vrijdag 11 november 2005 @ 16:21:
Een Windows programma hoort potentieel gevaarlijke situaties gewoon te herkennen en aan te geven dat de situatie potentieel onveilig is.

Linux werkt gewoon niet zo, ik zie "rm -rf" geen waarschuwing geven, "dd if=/dev/zero of=/dev/hda" ook niet. In Linux (*nix algemeen eigenlijk) wordt de gebruiker niet zo aan het handje gehouden en geld meer de "je tikte het in, dan zul je het wel zo bedoelen ook" regel

Nog zo'n cultuurverschil: In *nix geven commands meestal geen uitvoer als het goed is gegaan. cp roept bijvoorbeeld geen "x file(s) copied", aangezien dat in de lijn der verwachting lag. Gebeurt er iets anders dan verwacht mocht worden, krijg je daar bericht van. "dd" is hierop wel weer een uitzondering.

offtopic:
Gezien je post-history was mijn uitleg wat overbodig denk ik zo, misschien heeft iemand anders er nog wat aan.

[ Voor 37% gewijzigd door Gerco op 11-11-2005 16:48 ]

[Garyu]

Gerco schreef op vrijdag 11 november 2005 @ 16:45:
[...]


Linux werkt gewoon niet zo, ik zie "rm -rf" geen waarschuwing geven, "dd if=/dev/zero of=/dev/hda" ook niet. In Linux (*nix algemeen eigenlijk) wordt de gebruiker niet zo aan het handje gehouden en geld meer de "je tikte het in, dan zul je het wel zo bedoelen ook" regel

Nog zo'n cultuurverschil: In *nix geven commands meestal geen uitvoer als het goed is gegaan. cp roept bijvoorbeeld geen "x file(s) copied", aangezien dat in de lijn der verwachting lag. Gebeurt er iets anders dan verwacht mocht worden, krijg je daar bericht van. "dd" is hierop wel weer een uitzondering.

offtopic:
Gezien je post-history was mijn uitleg wat overbodig denk ik zo, misschien heeft iemand anders er nog wat aan.

Je moet echter wel als root ingelogd zijn. Als je sudo aanroept vermoed ik dat je nog geen root bent . En hoe dan ook, er wordt wat onverwachts gedaan, een password dat je normaal niet ziet bij het intypen verschijnt nu ineens wel, omdat je in een of andere exception situatie ziet. Leuk dat je niet bij het handje gehouden wordt, maar uitzonderingen zijn nu eenmaal uitzonderingen, en daar mag moet de gebruiker op gewezen worden .

[CyBeR]

Garyu schreef op vrijdag 11 november 2005 @ 17:12:
[...]

Je moet echter wel als root ingelogd zijn. Als je sudo aanroept vermoed ik dat je nog geen root bent .

Nee, maar je wilt 't worden.

En hoe dan ook, er wordt wat onverwachts gedaan, een password dat je normaal niet ziet bij het intypen verschijnt nu ineens wel, omdat je in een of andere exception situatie ziet. Leuk dat je niet bij het handje gehouden wordt, maar uitzonderingen zijn nu eenmaal uitzonderingen, en daar mag moet de gebruiker op gewezen worden .

Eh, nee. Als je niet weet wat je doet, moet je 't niet doen. Simpel. Een mentaliteit zoals die van jou is precies wat linux de verkeerde weg (die van windows) ophelpt. Straks worden we nog gevraagd of we wel zeker weten dat we de muis willen bewegen.

[Arioch]

Dit is het antwoord dat ik gekregen heb op de bugreport:

This is because when you use ssh with an explicit command (in the
example above, your command is sudo), ssh doesn't bother allocating a
pseudo-tty for your session, which means that sudo's password-hiding
is not done, since it is not running within a terminal, as far as it
knows.

To force ssh to allocate a pseudo-tty, use -t, as in:

ssh -t arioch@192.168.0.1 sudo tail -f /var/log/messages; exit

Use "man ssh" and search for pseudo-tty for more details.

Hope this helps,

--dkg

Als ik ssh aanroep met als parameter -t dan werkt het wel zoals het hoort.

[ Voor 9% gewijzigd door Arioch op 11-11-2005 17:56 ]

[Garyu]

CyBeR schreef op vrijdag 11 november 2005 @ 17:17:
Eh, nee. Als je niet weet wat je doet, moet je 't niet doen. Simpel. Een mentaliteit zoals die van jou is precies wat linux de verkeerde weg (die van windows) ophelpt. Straks worden we nog gevraagd of we wel zeker weten dat we de muis willen bewegen.

Bagatelliseren is leuk hoor, maar vooral een makkelijke manier om onder een discussie uit te komen. Waarom zou het verkeerd zijn van een systeem om een gebruiker bij te staan in wat hij wil doen? Dan was een ongeluk als Three Miles Island nooit gebeurd, dan zouden er minder vliegtuigen neerstorten, etc. Menselijke fouten, omdat ze hun systemen verkeerd bedienden of verkeerd interpreteerden. En zo zijn er duizenden en duizenden kleinere en grotere fouten gemaakt omdat mensen niet precies weten hoe een systeem werkt. Ik kan van mezelf rustig stellen dat ik bij lange na geen Linux-expert ben en dus veel fouten kunnen voorkomen door mezelf beter in te lezen. Maar ik kan ook met 100% zekerheid zeggen dat niemand foutloos is. En juist daarvoor zijn veiligheidsmechanismen, die kan je soms makkelijk, soms moeilijk inbouwen, met als gevolg dat het systeem (mens + computer) beter functioneert.

Als dat de verkeerde weg is, dan ben ik alsnog blij dat ik die verkeerde afslag genomen heb. Een computer is er om mij het leven makkelijker te maken, niet andersom..

[Wilke]

Garyu schreef op vrijdag 11 november 2005 @ 17:59:
Bagatelliseren is leuk hoor, maar vooral een makkelijke manier om onder een discussie uit te komen. Waarom zou het verkeerd zijn van een systeem om een gebruiker bij te staan in wat hij wil doen?

Omdat dit het systeem minder voorspelbaar maakt, en bovendien lastiger te scripten. Eigenlijk ook omdat ik verwacht dat het systeem vrijwel altijd verkeerd zal voorspellen wat ik wel en niet wil doen (zie: Windows). Semi-intelligentie op dat gebied kan nog veel gevaarlijker zijn dan gewoon 'dom doen wat ik zeg'. In dat geval ben ik me er tenminste van bewust dat ik moet nadenken wat ik intyp.

Zie Rule of Silence: When a program has nothing surprising to say, it should say nothing. en ook Silence Is Golden:

This rule has even greater force for confirmation prompts. Constantly asking for confirmation where the answer is almost always “yes” conditions the user to press “yes” without thinking about it, a habit that can have very unfortunate consequences. Programs should request confirmation only when there is good reason to suspect that the answer might be “no no no!” A confirmation request that is not a surprise is a strong hint of bad design. Any confirmation prompts at all may be a sign that what your interface really needs is an undo command.

Bovendien, als je niet perfect voorspelt wanneer het ding wel en niet vraagt om confirmation, is het systeem vanuit een scripting-perspectief gezien min of meer ondeterministisch geworden.

Garyu schreef op vrijdag 11 november 2005 @ 16:21:
Tsja, het is maar net hoe je het ziet blijkbaar. Dat je met een pistool in je voet kan schieten is eigenlijk gewoon een bug in het pistool. Het zou moeten bedenken dat dat niet zo hoort en dus niet schieten.

Ben ik het niet mee eens, dat lijkt me zeker geen bug, dat lijkt me 'by design'. Als ik de trekker overhaal wil ik dat het ding doet waarvoor het ontworpen is: schieten. Als het dat niet doet (om welke reden dan ook) zou dat zelfs nog gevaarlijker kunnen zijn. De controle over mijn apparatuur ligt bij mij en *niet* bij de apparatuur.

[ Voor 63% gewijzigd door Wilke op 11-11-2005 18:29 ]

[Z-Dragon]

Gerco schreef op vrijdag 11 november 2005 @ 16:45:
[...]

ik zie "rm -rf" geen waarschuwing geven [...]

Beetje kromme vergelijking: met de 'f' parameter geef je juist te kennen dat er niet naar gevraagd moet worden!

[CyBeR]

Garyu schreef op vrijdag 11 november 2005 @ 17:59:
[...]
Als dat de verkeerde weg is, dan ben ik alsnog blij dat ik die verkeerde afslag genomen heb. Een computer is er om mij het leven makkelijker te maken, niet andersom..

Ja. En om die reden moet 't ding doen wat ik zeg, en niet wat 'ie zelf goed dunkt. Dat maakt 't alleen maar moeilijker namelijk.

[Gerco]

Z-Dragon schreef op vrijdag 11 november 2005 @ 18:27:
Beetje kromme vergelijking: met de 'f' parameter geef je juist te kennen dat er niet naar gevraagd moet worden!

Dat klopt helemaal, daar ging het me ook niet om. Ik moest even snel een voorbeel bedenken en -f wordt zo vaak gebruikt bij rm, dat het bijna een standaard onderdeel van het commando is geworden^*. Als je er blij van wordt kun je wel "poweroff" of "rm -r /" gebruiken als alternatief.

^* Dat doen mensen omdat rm de (mogelijk irritante) gewoonte heeft om errors te geven bij non-existant files

[ Voor 13% gewijzigd door Gerco op 11-11-2005 18:44 ]

[wzzrd]

Mjah. Anyway, persoonlijk zou ik ervoor kiezen om toch te submitten en de jongens die die bugzilla bijhouden te laten bepalen of ze hem 'NEW' willen taggen of direct op 'CLOSED' willen zetten. Lijkt me meer hun beslissing dan die van ons. Beter een bug te veel gemeld, dan één te weinig. Da's de Rule of Wzzrd trouwens. Die stond er nog niet bij in Wilke z'n lijst

[ Voor 7% gewijzigd door wzzrd op 11-11-2005 20:53 ]

[Arioch]

Check even een paar posts terug. Ik heb het antwoord op de bugzilla report gepost
De oplossing is de "-t" flag, die er voor zorgt dat er een nieuwe tty geopend wordt, voor programma's die het zelf niet doen.