Maatregelen om risico te verminderen:

- Chrome als default browser instellen. Content met verwijzing naar $MFT geeft geen probleem binnen Chrome, wel binnen IE. (Ik heb Firefox niet getest)

- Hyperlinks in email waar $MFT in voor komt, blokkeren.

- Upgrade naar Windows 10;-).
(aub niet weer eindeloze discussies over Win, Linux of Mac, dat weten we nu inmiddels wel)

En Windows XP?

O ja, die kon je desnoods ook nog op het niet aanbevolen FAT32 laten draaien... ;>)

Binnen Firefox werkt de dead-lock ook, is dus ook gevaarlijk.

Wow. Hele lullig fout, maar na een reboot (of BSOD) is het weg en kan de gebruiker weer werken.

Zal het proberen. Ik heb wel wat anders wat er op lijkt.

Serviceaccounts die na 3 pogingen alsof het een normale gebruiker betreft geblokkeerd moeten worden. Ja dat vinkenlijstje van een auditor of een eigenwijze beperkte security administrator.
Leuk als je de hele service op die manier kan blokkeren een DDOS zonder echte netwerklast. Serviceaccount horen enkel via intern netwerk met een gecontroleerd context switch vanuit een valide toegewezen unprivileged user te kunnen plaatsvinden. Het betekent ook dat een enkele gebruiker met meerdere accounts toegang tot systemen kan krijgen.

Allemaal downgraden naar Windows XP. ;-)

Of 3x verkeerd inloggen is één uur geblokkeerd.
Waarbij het uur afhankelijk is van het doel, het kan ook een dag, of een week, of een ....... zijn.
Dit ter voorkoming van een brute-force aanval.

Verder heb je wel gelijk, we willen alles via internet kunnen doen, gewoon omdat het kan, niet omdat het nodig is.

@Ron de clou zit in "service accounts" Dat zijn de keys waaronder je een webserver MFT DBMS repsitory als basis service kan draaien zonder daarvoor een root (local-machine) als algemeen open iets gebruikt.
Met service accounts kun je aan containerisatie doen (cgroups als toevoeging) zonder een Docker een VM als tool/techniek in te zetten. Richt de service accounts in op de continuïteit van de onderliggende dienst (service). Het gemak van root(local service) enkel daar waar je geen extra risico loopt

Met de beperkte eindgebruiker accounts op internet met een lock policy na fouten wachtwoorden heb ik geen probleem integendeel het is een eis. Dat de strategie van beperkte eindgebruikers wordt doorgetrokken naar service accounts en high privileged accounts is een fundamenteel onbegrip van security.

Een voorbeeld:
Stel in het betalingsverkeer waar je vele tussenstations hebt laat je het doorgeven van de data afhangen van een bepaald account. Nu publiceer je dat account ook op het web via een interface b.v. voor onderhoud door de leverancier.
Drie fouten pogingen met dat account en heel het betalingsverkeer voor iedereen gaat plat. Een fraai ontwerp.

Is bekend en gesneden koek hoor als techniek. Ik heb het er over dat dat soort zaken vanuit os linux beheerders niet gefaciliteerd worden dan wel gewoon de boel saboteren. Als andere stap dat de processen/handelingen met scheiding van taken zgedaan worden odat de gevoelige informatie niet zo maar benaderbaar is voor de os nerds. De controle wie wat gedaan heeft door een derde figuur gedaan wordt waarbij je het sudo beheer in LDAP centraliseert.

Als je komt met een pam invulling moet je wel snel dekking zoeken want zoiets is natuurlijk "not done" net zoals het gebruik van een Shell of cli interface. Dat soort gebruik is gevaarlijk het hoort niet bij gebruikers. Niet mijn mening maar van linux os Nerds.

Ben je er ooit echt mee bezig geweest? Dan moet je de nuances opgevallen zijn. Su scripted maken is lastig hij vraagt om het password van de doel gebruiker. Met sudo heb je die niet nodig maar bedenk dat de profile settings van root doorkomen niet van je doel gebruiker. Er zijn nog een hele trits van alternatieven en onverwacht gedrag zoals het of niet blokken van tty lijntjes.

Dit soort design patterns zouden gewoon en opgelost vastgelegd en openbaar moeten zijn. Daar hoort dan een verplichting naar externe leveranciers bij. Deze komen nu als beleidsmakers door al weten ze niet eens wat high privileged accounts en service accounts zijn en wat het doel bij de klant is.Vervolgens komen de benadering met bossen van machines omdat zoiets te overzien en beheren zou zijn. Linux is toch gratis...

Misschien een tikkie para maar het is wel heel 'toevallig' dat de laatste weken de 2 OS'sen waar MS liever gisteren dan vandaag vanaf wil ineens heel erg kwetsbaar zijn en dat MS dergelijke issues in 10 wel schijnt verholpen te hebben. Komt op mij over alsof MS nu de gebruikers van 7 en 8.1 laat bombarderen met exploits waarvan MS weet dat deze in 10 niet aanwezig zijn.
Windows 7, maar zeker Windows 8.1, zitten nog steeds in de security fix onderhoud waarbij Windows 8.1 zelfs nog tot 2018 geheel ondersteund behoort te worden, incl. bugfixes. Waarom zijn deze OS'sen dan ineens kwetsbaarder dan 10? Ik ruik een MS misdaad.
En Chrome gebruiken? Kom op jongens, zitten we hier nu op een serieuze Security website of een pro Google (ik geef graag mijn privacy op aan Google) kleuter website?

Je bent idd para.

Het Security model van Chrome is helemaal zo slecht nog niet, laat je niet leiden door de Privacy emotie als het om security gaat. Ook Chrome kun je privacy vriendelijk inrichten, check even de Chrome hardening guide.

CISecurity Chrome Benchmark:

https://benchmarks.cisecurity.org/tools2/CIS_Google_Chrome_Benchmark_v1.1.0.pdf

Nee, dat heet een gezond portie argwaan............

Privacy emotie? Security is niet heilig maar privacy wel. Om privacy te kunnen hebben (en vooral houden) moet je beveiliging toepassen. Maar wel beveiliging toepassen maar ondertussen je privacy opgeven is hetzelfde als water naar de zee dragen want wat wil je dan eigenlijk beveiligen? Kip vs. ei verhaal want het één kan niet zonder het ander. Ik geloof graag dat Google z'n uiterste best doet om Chrome zo veilig mogelijk te krijgen maar de keerzijde is dat je hiervoor betaald met je surfgegevens want Google doet niets gratis en zeker niet vanuit de goedheid voor de mens. Maar dat geldt voor elke commercieel bedrijf.

De enige manier om Chrome te draaien zónder je privacy op te geven is Chromium te gebruiken en daar de CIS hardening Guide op toe te passen.
Dit heeft helemaal niks met para of emotie te maken, er zitten genoeg variabelen in Chrome (en niet in Chromium) die tracking kinderlijk eenvoudig maken. Geloven dat een advertentiebedrijf (want dat is Google) een standaard privacy-enabled browser maakt is simpelweg naïef.

Welk merk/type telefoon gebruik je?

Kleine uitleg:
Chromium is de OpenSource browser waarvan Google de source gebruikt voor Chrome.
Chromium is dus Chrome zonder Google............

Kan je uitleggen wat je daarmee bedoelt? Ik heb het volgende uitgevoerd als root:
En in een andere sessie als user ikke:
[code sudo -i -u ander pwd[/code]De inotifywait-sessie laat zien dat in beide gevallen geen bestanden uit /root worden gelezen, en met de optie -i worden de gangbare profile-bestanden uit de home-directory van ander gelezen, geheel volgens verwachting. Geen profile van root. Ik heb ook met env in plaats van pwd gedraaid en de environment-variabelen gedragen zich keurig zoals de man-page het beschrijft. Ik zie ook daar geen onverwachte zaken. Dus waar doel je op?

En als je bedoelt dat dingen onverwacht zijn die duidelijk in de man-page uitgelegd zijn, dan is in mijn ogen RTFM het juiste antwoord. Met een tool waarmee je rechten kan verhogen kan je gevaarlijke dingen doen, en dan mag je de gebruiker vragen aandacht te besteden aan hoe het werkt.

Niet blokken van tty-lijntjes? Dat het programma in de terminal (tty/pty) van de user die sudo aanroept draait is niet onverwacht, en de toegang tot andere terminals is afhankelijk van de rechten waarmee het opgestarte proces draait, zoals ik zou verwachten. Dus ook hier: wat bedoel je?

Een geroote Android 7 telefoon zonder Google of anderse social media apps plus een netwerk firewall, Firefox incl. addblock/cookiecrusher/scriptblocker, Eset AV, xprivacy als app firewal, DNS 666 als DNS loophole voor ads? Veilig genoeg toch? Of kun je nu geen punt meer maken?

Wat ik bedoel is het gedrag wat er tussen neus in lippen net niet staat. https://www.computerhope.com/unix/sudo.htm
Je kent vast wel dat er drie uid's een rols spelen effective real en originating. Met root bedoel ik de effective 0 id-je.
Veel consultants komen niet verder dan dat je met sudo enkel naar root switched. Ik zie in je voorbeeld dat je netjes een "-u ander" gebruikt zodat je het met een privileged account en service account kan doen.

Nu zijn er settings die via een login script uitgevoerd worden. Die zal je bij gewoon gebruik wel zien bij de switch niet.
Verklaarbaar als je het weet het zijn vaak lokale implementaties. Als je niet de system env globale setting wilt veranderen maar enkel via een profile een bepaalde ORA versie en andere tool settings dan zul je dat scripted mee moeten nemen.

Niet echt erg want alles draai al in een gelimiteerde specifieke user-context. Wel problematisch is dat OS sudo malloten elk commando wat je met de gelimiteerde user context tot de letter gespecificeerd willen hebben omdat zoiets hoort als sudo -root controleert. Als je dat niet sudo met root inzet wordt je raar aangekeken.

Heb je die specifieke user-context besef dan dat er attributen uit de password (shadow) file doorkomen. Zet nu een de umask voor root jouw user en dat privileged account net wat anders. Kijk dan eens welke waarde dat ding heeft na de user context switch. De homedir gaat goed niet de umask. Je moet dan ook even kijken of er een LDAP issue mee te maken kan hebben. Als je service accounts lokaal definieert en persoonlijke via LDAP heb je twee bronnen die door elkaar lopen. Tegen deze situatie liep enige jaren terug aan. Met veel moeite heb ik het uiteindelijk werkend gekregen.
Ik vermoed gezien de complexiteit dat dit de reden is dat men zoveel mogelijk van alles onder shared accounts en root laat doorlopen. In dit geval was sudo beheer nog duidelijk georganiseerd, je komt ook tegen dat de gebruikers het zelf mag invullen. (oeps wat was het doel?). Je lijkt hier de gebruiker neer te zetten als degene die tools en pakketten neerzet. Ik zie de gebruiker met functioneel beheerders bij de processen en informatiestromen.


Het shared memory gebruik is nogal beperkt voor IPC en user context switching. De clou om bij complexere pakketten in een usercontext switch mode te gaan kan dan het gebruik van poorten zijn. De eerste initiële werking is in een soort TTY mode, die moet dan wel doorkomen. Met sudo gaat dat goed. Met een ander alternatief voor sudo bleek dat geblokkeerd te worden.
Ik baalde omdat het ook betekende dat er hard code passwords bij de accounts achterbleven. Ook hier kreeg ik de opmerking van de OS mensen en PL's maak je niet druk wat niet weet wat niet deert.

Dan kom je met de vraag warm zou in een Multi tenancy benadering elke tenant willen scheiden?
Multienancy is het verdienmodel van een cloud benadering (hosting). Het is niet goedkoper om voor elke tenant met elk tool aparte machine te gaan neerzetten. Zoiets met VM's is akelig duur en complicerend.

Oké...
real, effective en saved, bedoel je?
Vanzelf...
De umask staat niet in /etc/passwd of /etc/shadow. In de man-page voor sudo wordt umask inderdaad niet vermeld, maar in de man-page voor sudoers worden de instellingen umask en umask_override beschreven. Bij umask staat:
Er is over nagedacht, er is een veilige default gekozen, en iemand die tegen verrassingen aanloopt moet nou eenmaal in handleidingen duiken om uit te vinden wat er aan de hand is, daar zijn ze voor. In de "see also"-sectie van de man-page voor sudo wordt netjes naar sudoers verwezen, trouwens. RTFM.
Als er verschillende bronnen zijn voor wat dan ook dan is dat verwarrend als je niet paraat hebt waar het vandaan kan komen. Daar loop ik ook met enige regelmaat tegenaan als ik het betreffende onderwerp al een poos niet meer onder mijn aandacht heb gehad. Dat kost dan even wat meer tijd, inderdaad, en als het té lastig is dan is dat reden om me af te vragen of dat wel een goede oplossing was, of de oplossing wel goed gedocumenteerd is, en of ik die documentatie wel goed weet te vinden, en zo nee, waar dat aan ligt.
Dat zou heel goed kunnen. Je kan je afvragen of, als dit een probleem is, de betreffende mensen wel voldoende gekwalificeerd zijn en voldoende beseffen dat ze hun gereedschap moeten kennen om het goed te kunnen gebruiken.
Omdat ik het woord "gebruiker" gebruikte? Ik bedoel de gebruiker van sudo, het programma waar we het over hebben. Een gebruiker van iets is letterlijk iemand die het gebruikt. Een systeembeheerder is ook een gebruiker, namelijk van de zaken die een systeembeheerder gebruikt. Een programmeur is gebruiker van een IDE, een compiler, een versiebeheersysteem. Een chauffeur is gebruiker van een auto.
Ik had uit "een hele trits van alternatieven en onverwacht gedrag" niet afgeleid dat je over onverwacht gedrag van alleen de alternatieven had, ik dacht dat het ook op sudo betrekking had wat je stelde, en dat kon ik dus terecht niet plaatsen.
Die vraag heb ik helemaal niet gesteld, maar goed..

Nog twee uit hun volgorde gelichte quotes:
Dat is geen probleem van sudo maar van mensen die de stap overslaan om te snappen waar ze mee werken. RTFM, zoals ik al schreef. Ik ben zelf als automatiseerder "opgegroeid" met die norm. Het werd iedereen regelmatig ingepeperd: lees handleidingen, zoek op hoe het werkt, sla dat nooit over, de antwoorden op je vragen zijn meestal goed te vinden, zorg dat je de weg in documentatie goed genoeg kent om wat je zoekt ook vlot te kunnen vinden. En dat heb ik ingepeperd gekregen in een organisatie waar het er in die periode behoorlijk hectisch aan toe ging. Ondanks het feit dat veel tijdsdruk en hectiek maken dat mensen makkelijk geneigd raken dat over te slaan vonden we het evident dat degelijkheid en zorgvuldigheid per saldo tijd bespaarden. Ik niet alle ins en outs van sudo uit mijn hoofd, maar ik weet waar ik het kan vinden, ik weet dat er manual pages voor sudo en sodoers zijn. En ik weet dat ik het doen en laten van programma's met tools als strace en inotify kan volgen als ik iets wil verifiëren. Geen vaardigheden voor een "gewone" gebruiker, maar de verantwoordelijkheid voor goed gebruik van sudo is ook niet iets om bij een gewone gebruiker te leggen. Als die consultants die je noemt niet blijken te kunnen wat in hun ongetwijfeld dikke cv staat dan doe je zoiets als een chauffeur inhuren die nauwelijks blijkt te kunnen rijden om vervolgens te beweren dat het aan de auto ligt.

Ik weet dat dat lang niet overal en bij iedereen goed gaat, maar ik vind het onterecht om dan de indruk te wekken dat het aan sudo (of een andere tool) ligt dat het zich onverwacht gedraagt voor mensen die niet de moeite hebben genomen om te begrijpen hoe het zich gedraagt. Het is beschreven, en die beschrijving is er niet voor niets. Als je vindt dat je zwaargewicht genoeg bent om het te gebruiken voel je dan ook maar verantwoordelijk om het te begrijpen.

Thanks, ik wilde niet perse een punt maken, het was gewoon een vraag om te checken of je echt para bent.

Ja dus :)

Yeah, ik ga alle toestellen binnen mijn organisatie uitrollen met deze config... Alle toestellen lekker rooten, omdat dat veiliger is dan Chrome.... Denk na man, wat doe je hier?

Zou iemand mij kunnen vertellen of dit dos-lek in Windows 7 en 8.1 intussen al door Microsoft opgelost is? Ik ben het spoor een beetje kwijtgeraakt. Het laatste dat ik heb kunnen vinden is het NCSC-bericht van 6-6-2017:

https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2017-0503+1.02+Kwetsbaarheid+ontdekt+in+Microsoft+Windows.html

Maar in dit NCSC-bericht wordt nog geen oplossing beschreven of aangekondigd.

Bij voorbaat veel dank.

Harry

Zou iemand mij kunnen vertellen of dit dos-lek in Windows 7 en 8.1 intussen al door Microsoft opgelost is? Ik ben het spoor een beetje kwijtgeraakt. Het laatste dat ik heb kunnen vinden is het NCSC-bericht van 6-6-2017:

https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2017-0503+1.02+Kwetsbaarheid+ontdekt+in+Microsoft+Windows.html

Maar in dit NCSC-bericht wordt nog geen oplossing beschreven of aangekondigd.

Bij voorbaat veel dank.

Harry