Wegens bedrijfsbeleid ben je toch nog 18 dagen onbeschermt. Want zelfs al hebben ze een patch moet je mooi wachten op Patch Tuesday.

Op 14 mei het probleem erkennen en op 11 september nog steeds geen patch?

Karma4: Kun je me, met al jouw expertise over Microsoft uitleggen hoe dat zit?

Nieuwe kans op dinsdag 9 oktober. En dan moet het nog in Enterprise omgevingen getest worden dus daar komt er nog wel een weekje bij.

Ik mompel even iets van... Servers vs Werkstations. Op servers heb je vaak een redelijke schone en beheersbare omgeving. Desktops zijn vaak een puinhoop van vele software producten. Wat updates aanzienlijk lastiger maakt.

Daarnaast is er vrij weinig te zeggen zonder dat je de exacte informatie weet. We kunnen hier wel gokken, maar dat kan je beter in een casino doen.

Klopt wat je zegt over Windows desktops, soms een puinhoop van software producten met elk hun eigen update mechanisme.
Beter gebruik je dus een Linux Distro of Mac OS waarbij software uit repositories komt en updates via het OS meekrijgt.

Maar daar gaat het hier nu niet om. Microsoft is een rijke mega grote firma die niet in staat is security patches op tijd uit te brengen, zelfs nadat de 120 dagen van openbaarmaking verstreken zijn.

Dit is nu precies wat ik bedoel. Dat kan toch niet? Lekken en beveiligingsissues heb je altijd wel, ongeacht welk systeem je draait. Maar die totaal verknipte "Patch Tuesday", dát is de grootste bedreiging voor Windows-gebruikers. Sterker nog: ik zie "Patch Tuesday" als een ernstige veiligheidsissue die catastrofaal kan uitpakken als het een keer goed mis gaat. Die gasten in Redmond moeten zo snel als mogelijk dit achterlijke updatebeleid per onmiddellijk de nek omdraaien en een beter updatebeleid uitdenken.

Nu zijn er mensen die constant mekkeren over Linux, maar op de desktop distro's is dit ongelooflijk veel beter geregeld. Zodra er een issue is krijgen we binnen de kortste keren een patch aangeboden die de issue(s) plet(ten). Ja, je krijgt inderdaad véél meer updates voor de kiezen, maar dat is niet erg omdat updaten onder Linux in de regel altijd soepel verloopt, de updates snel klaar zijn en je - met uitzondering van kernelupdates - je computer niet opnieuw hoeft op te starten.

Dan ben je ook zeker op de hoogte dat Linux net zo hard faalt kwa patchen en backporten van patches naar stable kernels is al jaren een hel [1].


1 : https://twitter.com/grsecurity/status/995790864407564289

Maar wat is nu de impact op mij als gewone gebruiker? In mijn dagelijks gebruik gebruik ik de JET engine niet direct.
Het zou helpen als er meer informatie wordt gegeven over welke acties nu veilig of juist onveilig zijn,

Met het beleid is niet direct iets mis. Gemelde maar verder onbekende lekken worden op bekende dagen gepatcht, voor het publiceren van de kwetsbaarheid. Het is dan dus gedicht voordat het lek bekend is. In bijzondere gevallen zijn er noodpatches die tussendoor gereleased worden. Bij een directe reële dreiging wordt er dus ingegrepen. In dit geval ontstaat er een probleem omdat er geen patch voor de deadline is, maar dat is geen intrinsieke fout van het updatebeleid.

Het is jammer dat Linux- en Windows-gebruikers elkaar zo vaak bestrijden en dat ook nog op zaken die vaak niet of nauwelijks relevant zijn. Om verder te komen moeten we van dat denken in kampen af. De aanvallers kan de kleur van je shirtje in ieder geval weinig schelen.

Repositories zijn ook niet zaligmakend. Geen van de OS'en heeft de oplossing die alle gevallen redelijk dekt.

Als je Microsoft Office op je computer hebt geïnstalleerd heb je grote kans dat de JET Engine ook op je PC staat, aangezien Oulook, Access, maar ook VBA gebruik ervan maakt.

Kijk even of het proces "acecore.dll" meedraait op je systeem. Of anders zoek je even met de zoekfunctie naar "acecore.dll". Meestal is deze te vinden in de mappen "C:\Windows", "C:\Program Files" of in de map "Common Files" in laatst genoemde directory.

WTF? Alweer één?

Aangezien ik geen microsoftspecialist ben zal ik je proberen te helpen met de analyse.

Ik zag dat je vorderingen maakt met de redeneringen. Als iets te moeilijk is voor gebruikers, zal het niet geaccepteerd worden.
https://www.security.nl/posting/578070/Google+noemt+Androidtelefoons+met+recente+security-updates


Ik weet niet of je de JET engine kan plaatsen. Laten we daar eens beginnen.
Het is iets wat in de integratie van pakketten speelt. Gaat om informatiekoppelingen. En dat is nu net iets waar ik meer in thuis ben. Deze naam is er een vanuit de oudheid het speelde als toosl van verschillende leveranciers data wilde laten uitwisselen https://www.microsoft.com/en-US/download/details.aspx?id=13255 Je zit dat deze oude (2010) al een vervanger noemt.
Er zijn downloads voor (free) terwijl deze onderdelen bijvoorbeeld met Excel meekomen. Standaard staat het er niet op, het is geen onderdeel van het OS. Als je SAP (BO) Cognos (IBM) Tibco als server proces hebt draaien willen de gebruikers dat heel graag zo in hun excel kunnen oppakken. Daarom zie je deze onderdelen vaak terug n de cliënt desktop stack.

Het is jaren verouderd en nieuwere interfaces zouden in gebruik moeten zijn. Nu is het releasemanagement op servers en zeker met Linux stacks vaak dramatisch.
https://help.sap.com/viewer/c90214be0d934ebdb6f3bce29c63c0ff/15.2.1/en-US/69c5ab5d9cef43578929a4434d3ad874.html
Je raakt hier toevallig een van de redenen van de faal van de linuxdesktop, kijk eens naar het wollmux verhaal.


https://support.microsoft.com/en-gb/help/299974/using-microsoft-jet-with-iis
"ASP also supports using the Microsoft Jet database engine as a valid data source. The Access ODBC Driver and Microsoft OLE DB Provider for Microsoft Jet are not intended to be used with high-stress, high-concurrency, 24x7 server applications, such as web, commerce, transactional, messaging servers, and so on."

Ik ben meer gecharmeerd van JSON XML en native DB engines voor het echte werk.
Omdat ECMA open is gaat een XLSX ook prima zonder aparte drivers.

Uit de beschrijving: "however it does require user interaction since the target would need to open a malicious file."
De gebruiker moet zelf het bestand openen / aanklikken. .exe zip waar de gebruiker van weet dat er code gaat lopen....
Tegen PEBCAK die overal op klikken en van alles installeren is geen kruid gewassen.

Dat zelfde geld voor de nerds die alles met root doen, dan wel sudo root open hebben staan, omdat dat zo makkelijk is.

JAWEL! Dit is er echt wéér eentje! Heeft Microsoft dan niets geleerd van al die vorige keren. Laten ze nog steeds hun gebruikers in de kou staan? Jawel!

Lijkt weer eentje in de reeks dat je moet weten dat niet zomaar alles moet aanklikken.
Gelde des te meer bij FOSS. Je kunt wel van alles van alles in de code zien, psstttt klikje doen .... Het verdienmodel zou zo maar kunnen zijn dat je gedkidnapt wordt in en geloofsgemeenschap en vor je het weet uitgelkeeld worrdt..
https://www.security.nl/posting/578228/Toekomst+Linux+in+gevaar%3F%21

Wie trapt er nog in die Microsoft spin-doctoring?

Gevaarlijke is de foss spin doctoring. Geen securitu of informatieveiligheid enkel een OS flaming om het geloof.

Heb je nog wat inhoudelijks op de analyse hoe gebruikers in organisaties hun informatieverwerking doen?
Niet het klikvee dat voorgeschreven handelingen uitvoeren maar eg de marketing analisten boekhouding bedrijfsanalisten.
Je komt in deze hoek:
https://www.datacamp.com/community/tutorials/python-excel-tutorial Kopieer het naar de desktop met zelf geinstalleerde tools en gebruik ongecontroleerd de meest gevoelige data.

Ja, precies dat soort spin-doctoring bedoel ik! Bent u misschien een Microsoft aanhanger? Of zelfs in dienst van Microsoft?

Nee, ik zie enkel wat foss aanhangers voor kwaad aanrichten in organisaties met hun fud. Dat is erg en triest genoeg.
Om een beeld te geven het soort fouten als deze 4:
https://blog.xebialabs.com/2018/07/19/4-software-delivery-mistakes-that-are-blocking-your-continuous-delivery/

Het zou aardig zijn als je als voorbeelden van het soort dingen die foss-aanhangers aanrichten een voorbeeld zou geven dat gaat over wat foss-aanhangers aanrichten. Dit gaat over continuous delivery en het noemt niet eens specifieke platforms.

Maar behalve het tweede punt ("Not aiming to deliver software daily") snap ik dat de punten ook op andere dingen dan continuous delivery betrekking kunnen hebben. Ze doen me zelfs denken aan een situatie die ik ooit heb meegemaakt. Ik werkte op een mainframe-site waar die kritiek allemaal niet van toepassing was, daar werd zeer professioneel ontwikkeld. Alleen werd het mainframe steeds meer als een verouderd platform gezien en moest het allemaal wat hedendaagser. Ontwikkelaars die met de "nieuwe wereld" aan de gang gingen, en daar waren ook ervaren mensen voor aangetrokken, bleken inderdaad heel erg in hun eigen wereldje te zitten, veel te veel op de tools en hun werkwijzen gericht te zijn en te weinig op het resultaat. En omdat hun applicaties met die op het mainframe moesten communiceren bleek ook nog eens dat ze heel sterk op hun favoriete techniek waren gericht en niet eens op alle techniek die meespeelde. Waren dat foss-aanhangers? Welnee, dat waren .NET-ontwikkelaars.

Dat je dit aan kan treffen bij het slag mensen dat als techneuten of nerds wordt aangeduid is duidelijk. Een professionele organisatie vangt dat op door er ook goede mensen met een functionele insteek en goede projectleiders op na te houden. En goede securitymensen, natuurlijk. Dan kunnen die op de techniek gerichte nerds op hun waarde laten zien in de dingen waar zij in uitblinken.

Als jij voortdurend meemaakt dat het niet goed gaat bij foss-aanhangers dan vermoed ik dat jij bij organisaties rondloopt die hun organisatie niet in alle uithoeken van het geheel goed op orde hebben. Is het niet eigenlijk slecht management waar je op af moet geven?

Slecht en zwak management wordt juist ook heel erg beïnvloed door allerlei nieuwsberichten. Dat gaat dan met name over open source als de oplossing want geen licentiekosten.
Met overheden, de gemeentelijke, kun je zo een aantal cases vinden. Huren de externe bureaus in van de "big four" je krijgt dan "lean six sigma" als besparingsplan. Het 9 vlaks model Maes en natuurlijk de outsourcing offshoring.


.Net applicaties direct met een mainframe, sorry ik ken ze niet. Geoon omdat de interfaces zover ik weet niet bestaan. Dan kom je bus ontsluitingen.of iets als https://developer.ibm.com/mainframe/2017/09/13/call-an-api-from-a-zos-application/
Afijn Windows kom ik dan als desktop endpoint tegen waarbij die beheerders-nerds in een meewerk stand staan Dat is geheel anders in de Linux foss die de negatieve tegenwerkende houding tonen.
Slechte IO . machine performance onderuit gehaalde security het is schering en inslag in de Linux hoek. Waar dat nu aan ligt...tja. Zodra ze komen met het is Linux en dat is onfeilbaar dus de problemen bestaan niet heb ik het wel gehad.

Dat jij in jouw omgeving last zegt te hebben van Linux beheerders vind ik heel zielig voor je. Het is jammer dat je anoniem bent, zodat er geen hoor en wederhoor kan worden gedaan bij deze beheerders. Hoe dan ook kan je met jouw ervaringen, in jouw kleine wereldje, niet alle beveiligings- en andere problemen met Microsoft Windows eventjes wegpoetsen of deze vergelijkbaar veronderstellen met Linux. De echt grote spelers in de automatiseringswereld (Google, Amazon, alle supercomputers om er een paar te noemen) maken niet voor niets gebruik van Linux.