Zeroday-lek in uefi-driver treft mogelijk meer laptops dan ThinkPads

Een zeroday-lek in een uefi-driver die Lenovo gebruikt voor zijn ThinkPad-laptops, is mogelijk ook te misbruiken op laptops van andere fabrikanten. De kwetsbare code is afkomstig van een externe softwareleverancier volgens Lenovo en mogelijk door Intel zelf verspreid.

De kwetsbaarheid is ontdekt door beveiligingsonderzoeker Dmytro Oleksiuk, die een exploit op Github publiceert. Het lek zit in een uefi-driver en maakt het mogelijk het flashgeheugen te beschrijven door de beveiliging hiervoor te omzeilen. Daarna kan een aanvaller vrijelijk scripts uitvoeren via System Management Mode, een diepe beheerlaag met hoge toegangsniveaus die normaal alleen voor de cpu toegankelijk is.

Op die manier is Secure Boot uit te schakelen en zijn beveiligingsfuncties als Virtual Secure Mode en Credential Guard op Windows 10 Enterprise te omzeilen. De onderzoeker heeft zijn exploit ThinkPwn genoemd. Een patch is nog niet beschikbaar, maar de onderzoeker heeft het lek toch in de openbaarheid gebracht, naar eigen zeggen omdat 'het zijn doel is om informatie te delen'. De kans dat de exploit publiekelijk misbruikt wordt, acht hij heel klein.

In de comments op zijn blog wordt erop gewezen dat een deel van de kwetsbaarheid op een bug in Intels referentiecode gebaseerd lijkt te zijn. Intel zou dit in 2014 al verholpen hebben, maar de kans bestaat dat de makers van uefi-software de fix nog niet verwerkt hebben.

Lenovo’s Product Security Incident Response Team is op de hoogte van de kwetsbaarheid en stelt dat meerdere pogingen om samen te werken met Oleksiuk op niets uitgelopen zijn. Volgens Lenovo is de kwetsbare System Management Mode-code door 'minstens een van vier onafhankelijke bios-leveranciers' verstrekt.

Lenovo werkt nu samen met de uefi-softwarebedrijven en Intel aan nieuwe versies van de driver die het probleem moeten verhelpen. Niet bekend is welke systemen van andere fabrikanten getroffen zijn. The Register verwijst naar een tweet van iemand met een HP Pavilion dv7 die de bug bevat, een laptop uit 2010.

Reacties (51)

[Verwijderd]

De PoC heeft het over een mogelijke (opzettelijke) backdoor. Als ik zie wat de Intel referentiecode doet; letterlijk als een function pointer de code die user land mag meegeven als parameter uitvoeren, dan begrijp ik waarom de security-onderzoeker die conclusie maakt.

CommunicationBuffer geef je mee, en dan:

v3 = *(VOID **)(CommunicationBuffer + 0x20);
v4 = CommunicationBuffer;
*(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);

Dus ja, dan is het gewoon die v3 struct op 0x20 verder dan je parameter zetten, een eerste member van 0x8 lang op NULL zetten en ..

Struct.Context = NULL;
Struct.Handler = Handler;
*(VOID **)((UINT8 *)Data + 0x20) = (VOID *)&Struct;

... laten uitvoeren.

Status = SmmBase->Communicate(SmmBase, ImageHandle, Data, &DataSize);

Ik begrijp niet waarom Intel zulke stomme referentiecode maakt. Als dit in priveledged context draait, dan voer je toch niet gewoon code in buffers die unpriviledged processen kunnen beinvloeden uit?

Vroeger was het nog spannend, met buffer overflows of zo. Maar dit is echt gewoon "pfuh".

[TJHeuvel]

'referentiecode' mist natuurlijk vaak deze checks, Intel moet zeker hiervoor een waarschuwing geven maar zo heel schokkend vind ik dit niet.

[equit1986]

en nu graag in jip&janneke taal
Ieder z'n eigen vak, maar wat je nu neerzet is voor hocuspocus.

[osmosis]

De helft van de sleutel in het slot laten. Enkel een schroevendraaier nodig om de slot open te draaien. Mits je weet ervan bewust bent dat de helft van de sleutel nog erin zit.

Zoiets ongeveer in jip&janneke taal

[Verwijderd]

Het is eigenlijk een slot dat het mogenlijk maakt voor om het even welke sleutel of langwerpig voorwerp om alle pinnen te laten loskomen.

• Het zit in een security feature (UEFI), dus het hoort bij het slot
• Om het even welke gebruiker van het slot (= sleutel) kan het slot zeer eenvoudig ontgrendelen

De helft van de sleutel zit er zelfs niet in. Het is eerder een standaard feature om het slot te ontgrendelen met een schroevendraaier.

[Verwijderd]

In Jip en Janneke taal: dit is er opzettelijk ingestopt. Volgens mij is het een backdoor en/of een truck opdat vele UEFI implementers dit zouden copy-pasten. Ééntje die zo successvol is geworden dat het is beginnen opvallen. De security-researcher heeft dit gezien en heeft in een handomdraai een proof-of-concept gemaakt die aantoont hoe dom sommige backdoors in elkaar zitten.

Iemand met beginnerservaring programmeren weet dat dit niet kan. Om het soort code waar het hier om gaat werkend te krijgen zal je geen beginner meer zijn. De referentiecode die Intel maakt wordt ook niet door beginners gemaakt. De implementers zijn dat misschien soms wel en daarom copy pasten ze van Intel's referentie code.

Ik steek dit helemaal niet op incompetentie. Voor mij als ervaren programmeur is dit zeer duidelijk met opzet gedaan.

[blorf]

Ik heb meer het idee dat ze (mogelijk in overleg met hun 'wederhelft') secure-boot willen veranderen omdat die te simpel is te omzeilen (niet door hackers maar door de PC-eigenaars zelf).

Sowieso een vreemd gebeuren, dat secure-boot. Vandaag met een HP bezig geweest, proberen te laten booten van een usb-stick met UEFI loader. Op de een of andere manier blijft het systeem na een software-shutdown in een bepaalde state waardoor hij random wel/niet wil opstarten. De stekker eruit en wachten tot de mobo-led uit is helpt. Dan is ie het 'vergeten'. Alleen geen idee wat. Niet echt grappig, een PC die buiten de storage om informatie vast houdt als ie 'uit' staat.

[Reactie gewijzigd door blorf op 23 juli 2024 08:11]

[Verwijderd]

State is iets wat een CPU of BIOS nooit of in zeer beperkte en goed gekende mate maar mag hebben. Voor deze reden. Zeker als state het (security) gedrag van één en ander beïnvloed.

Ik pleit ervoor om nooit state zomaar toe te laten in hardware. Vooral niet wanneer die state gedrag kan beïnvloeden. State leidt tot persistente backdoors die niet alleen zeer moeilijk maar ook onmogelijk te detecteren zijn door software (zoals virusscanners, of kernels, of package management, of wat dan ook waar wij sterfelijke gebruikers van uit gaan).

Ik vraag met nadruk aan de machine bouwers en integratoren: integreer geen hardware, geen enkele, die persistente state vereist om functioneel te zijn.

Na power-down hoort alles terug op nul te staan. Alles. Ja alles.

[robvanwijk]

Na power-down hoort alles terug op nul te staan. Alles. Ja alles.

Interessant idee (was een tijdje terug ook een BlackHat of DefCon talk van, maar geen idee op welk keyword ik zou moeten zoeken om het terug te vinden ). Helaas vraag ik me af hoe haalbaar het is. Je BIOS / UEFI settings zijn immers een form van persistent state, net zoals je bootloader en als ik echt vervelend wil zijn: je real-time clock ook. Hoe wil je zelfs maar booten (je eerste stukje software vinden) zonder dat soort mechanismen?

[Verwijderd]

Alles moet terug naar nul gaan. Dé uitzondering is die klok. Maar zelfs dat liever niet. Vraagt toch maar vooral batterijen en zo van die stomme onnodige componenten. Synchronizeer de klok achteraf maar. manieren zat: Galileo, GPS, NTP: ze geven allemaal zéér precies de huidige tijd. In 2016 hebben de meeste embedded devices wel of een netwerk of een GPS of een Galileo mogelijkheid. Gebruik dat i.p.v. de klok als state te bewaren. We willen het eigenlijk niet. Totaal niet.

Als uw project manager hardware-state wil: schijt hem dan uit. Nee serieus. Hij is een debiel. Werk niet voor hem. Ik meen dat. Ga voor een ander bedrijf werken, en laat deze persoon zitten. Ze sterven wel uit. Wees gerust.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:11]

[robvanwijk]

Hebben we het alleen specifiek over embedded devices, of over allerlei soorten apparaten (inclusief bijvoorbeeld reguliere desktops)? In dat laatste geval lijkt het mij nogal "met een kanon op een mug schieten" om een GPS / Galileo receiver in te bouwen alleen maar zodat er geen batterij in hoeft. Vertrouwen op NTP maakt je kwetsbaar voor bepaalde aanvallen (een compleet verkeerde, gespoofde timestamp kan de geldigheid van certificaten in het honderd schoppen).

Op dit moment werk ik niet aan hardware designs, dus over dat verdere advies van je hoef ik me gelukkig geen zorgen te maken.

Ik ga toch nog even proberen of ik die talk ergens kan vinden!

[Verwijderd]

Mnee weldegelijk over allerlei soorten apparaten. Ieder toestel moet in principe (en in realiteit) autonoom kunnen werken.

Dat is geen kanon op een mug. Een toestel dat niet autonoom kan werken is een slecht toestel dat U niet en niemand niet aan vrienden of klanten hoort te adviseren. Ook niet al heeft uw bedrijf het gemaakt. In dat geval vooral niet.

Wie zegt dat iedere applicatie die perfecte tijd of klok moet hebben? Mijn Scooba en Roomba kunnen perfect mijn living stofzuigen en dweilen zonder dat ze jouw Galileo en/of GPS en/of NTP datum kennen. Mijn Frigo en mijn tuin-grasmaschine ook. De meerderheid van mijn robots voor de komende tien jaar, ook.

Laten we toestellen maken die dit wel kunnen.

Met vriendelijke groeten,

Philip

[robvanwijk]

Wie zegt dat iedere applicatie die perfecte tijd of klok moet hebben? Mijn Scooba en Roomba kunnen perfect mijn living stofzuigen en dweilen zonder dat ze jouw Galileo en/of GPS en/of NTP datum kennen. Mijn Frigo en mijn tuin-grasmaschine ook. De meerderheid van mijn robots voor de komende tien jaar, ook.

Dat er een boel apparaten zonder kunnen is geen oplossing voor de apparaten die niet zonder kunnen; deze argumentatie vind ik nogal een zwaktebod...

Ik denk dat je dit waarschijnlijk wel interessant zal vinden:
https://www.youtube.com/watch?v=rcwngbUrZNg
http://blog.invisiblethin...rs/2015/state_harmful.pdf
Ze krijgt het niet voor elkaar om state af te schaffen; wel lijkt haar aanpak een stateless computer mogelijk te maken (met de kanttekening dat alleen de laptop zelf stateless is; het ding kan niks zonder een speciaal geprepareerde USB-stick).

Nogal logisch dat ik het niet kon vinden; het was niet BlackHat of DefCon, maar CCC... *schaam*

[Reactie gewijzigd door robvanwijk op 23 juli 2024 08:11]

[equit1986]

Bedankt voor de heldere uitleg!

[Verwijderd]

Bedankt voor de heldere uitleg!

Mijn excuses dat ik niet eerder door had dat ik te technisch was. Het is net mijn opdracht om zo veel mogelijk mensen te betrekken bij de wonderen van de techniek.

Soms verlies ik wel eens het doel uit het oog. Dan zit ik weer te ver.

Groetjes,

Philip

[equit1986]

Ik ken het verhaal. In mijn vak (winkel automatisering) kijken mensen mij ook vaak glazig aan als ik de diepte in ga.

Maar nogmaals bedankt. Want dit moet door onze systeembeheerders worden bekeken of wij vatbaar zijn of niet.

[Verwijderd]

Zo is dat. Wij programmeurs vertellen jullie wat we zien. Laten we Dmytro Oleksiuk dankbaar zijn dat hij wat hij vond met ons deelde.

Maar weet, als systeembeheerder, dat het percentiel 'goede' versus 'slechte', gelijk is aan wat de samenleving biedt.

En dat in het percentiel 'goeden', je moet rekening houden met overschilligheid plus de overheid die in haar botheid soms ook de goeden als doelwit neemt.

Dat wil zeggen dat de goeden angstig zijn. Ik merk dat iedere dag: zij die het kunnen zijn bang om't te tonen: want de overheid zoekt naar wie het kan. Zij zijn niet slecht in persoon, en zouden nooit een vlieg kwaad doen. Maar het zijn kwetsbare (slimme) mensen. Ze willen ook helemaal niet daar mee bezig zijn. Maar ze zijn er natuurlijk wel mee bezig. Het is hun beroep.

We hebben die mensen nu net wel nodig. We moeten ze net wel activeren. Zij moeten net niet bang zijn. Dat is heel moeilijk.Want zij kennen iets wat veel mensen niet snappen. En de wetgevers, de rechters, snappen het ook niet. Dat maakt het extra moeilijk.

Het is nieuw. De samenleving moet een nieuw soort drukkers toelaten.

[Verwijderd]

Tweakers is dan ook een website waar veel techneuten rondhangen. Ik vind het een beetje onnodig om in die context jip & janneke taal te gebruiken.

[equit1986]

je hebt techneuten en techneuten. zoals ik al zei, ieder zijn vak jargon.
niet iedereen snapt waar ik het over heb als ik praat over OPOS koppelingen en VIC protocollen.
Dus een iets minder technische uitleg over een best bijzonder onderwerp is zeker wel gewenst.

[SwiftPengu]

Wat heb je nu aan kennis die niemand anders begrijpt? Ik snap zijn verhaal maar gedeeltelijk, dus ik moet nu maar geloven dat zijn verhaal klopt.

In deze context is het misschien niet zo relevant, maar het helpt echt enorm als je je ideeën met anderen kunt communiceren. Op die manier vind je denkfouten en krijg je nieuwe inzichten.

[Mic2000]

Ik ben ook heel benieuwd hoeveel tweakers dit volgen, maarja het klinkt wel dat hij de skills heeft om het te begrijpen... Daarom de +3, ongeacht dat het grote gross er niets mee kan.

[Reactie gewijzigd door Mic2000 op 23 juli 2024 08:11]

[innerchild]

Maar toch die buffer van de x context heeft een minimale dwars calculatie nodig waarbij de interfentie van de 4 member van 0x008 ook nog een rol speelt.. Anders gaat het niet werken....

[Smultie]

https://cdn.meme.am/instances/500x/36278679.jpg

[Magyku30]

Dit is dus niet mogelijk bij de zakelijke HP elitebook en probook line-up die vanaf 2014 worden geleverd met Surestart en Dynamic Protection. Een aparte chip op het moederbord die realtime monitort of er code wordt gewijzigd in de Bios flash module. Wanneer dit wordt geregistreerd wordt binnen 10 seconden de Bios teruggezet naar veilige code. Zie http://www8.hp.com/us/en/...w/clientsecurity/20140611
Filmpje met uitleg hier: https://m.youtube.com/watch?v=10xH_puklMU

[Reactie gewijzigd door Magyku30 op 23 juli 2024 08:11]

[johnkeates]

Dit beschermt je helemaal niet, en heeft er dan ook geen zak mee te maken. Daarnaast zijn ze ook gewoon kwetsbaar, in elk geval op ProBook 655 G2 (die stond er naast samen met een geïnteresseerde collega ) een EliteBook Folio 1040 G3 hier werkt de exploit gewoon. Ik heb hem alleen nog maar vanaf een shell gedraaid om te kijken of de firmware kwetsbaar is, en dat is ie. In theorie kan je dan door EFI_BASE_PROTOCOL.Communicate() te implementeren het ook vanuit elk OS dat op de laptop draait doen. Je hebt alleen nog maar lokale rechten nodig om EFI communicatie te doen (Waarschijnlijk EFI Runtime Services) en je kan vanaf elk stukje malware een permanente rootkit/backdoor op computers afleveren.

Dat er een extra chip in zit is leuk, maar als die chip niet kan communiceren of de voeding uitgeschakeld wordt kan het NVRAM en BIOS Flash niet beschermen. Daarnaast acht ik de kans klein dat die extra chip ook iets tegen een ring -3 rootkit kan doen in Intel's ME, die je vanaf SMM kan kraken, en op z'n eigen CPU (een Arcfour) met eigen flash en RAM in de PCH draait en altijd aan staat, ook op +5vsb van je PSU zolang er stroom is maar je computer toch uit staat.

[Reactie gewijzigd door johnkeates op 23 juli 2024 08:11]

[shufflez]

De ProBook 655 G2 is een AMD machine? Daarop is voor zover ik weet geen SureStart beschikbaar, dat zou kunnen verklaren waarom exploit daar werkt. Zou het graag eens op mijn machine testen (1040 G3), heb je toevallig linkje met how-to voor n00bs?

[johnkeates]

Hmm, ik heb waarschijnlijk het verkeerde nummer gepost, want hier zit gewoon een vPro Intel in Even kijken.

De howto staat trouwens op GitHub, je moet wel eerst Visual Studio hebben.

[Verwijderd]

Ik denk dat je met dit wel genoeg zal hebben om de boel te compilen.

[johnkeates]

Volgens mij gaat dat niet werken, de EDK2 die je nodig hebt om hem te builden vereist in z'n bat script VS tools.

Waarschijnlijk is er in no-time wel iemand die een binary online zet, maar of je hem dan zou moeten draaien is maar de vraag... veilig is het niet.

Ik denk dat ik ga proberen of hij in OVMF ook werkt, dat zou wat zijn.

[Reactie gewijzigd door johnkeates op 23 juli 2024 08:11]

[Eric Oud Ammerveld]

Hmm 10 seconden is voldoende tijd om heel veel uit te voeren...

[Verwijderd]

Die 10 seconden biedt inderdaad letterlijk geen enkele toegevoegde waarde. Na tien seconden priviledged mode is het eenvoudigweg totaal en volledig game over voor alle beveiligingssystemen van je computer. Het geeft zelfs een false sense of security, wat dus het eigenlijk onveiliger maakt. Want nu gaan de security "specialisten" die het niet snappen dat als beveiligingsfeature bekijken. Daardoor maakt het het net onveiliger.

[shufflez]

De bescherming wordt zowel real-time als pre-boot uitgevoerd en 'malicious' code daarom ook direct geblokkeerd, dat is de toegevoegde waarde. Het kan ongeveer 10 sec duren voordat de EEPROM opnieuw geschreven is, maar in die tijd is er geen interactie mogelijk met systeemcomponenten vanuit BIOS. Iemand ervaring met schrijven van exploits? Dan kunnen we testen?

[Blokker_1999]

Als je de titel leest zou je denken dat het probleem beperkt is tot laptops met een UEFI van een IBV, maar als de slechte code reeds in de referentie implementatie van Intel terug te vinden is dan lijkt het mij dat mogelijk toch elk moederbord met UEFI aan boord een potentieel risico loopt (niet enkel laptops, en niet enkel systemen van OEMs, maar ook zelfbouw).

[Mizgala28]

Dus als je BIOS niet standard UEFI aan heeft (bijvoorbeeld door Windows 7) dan kun je alsnog aangevallen worden neem ik aan?

[MneoreJ]

Niet echt verbazingwekkend -- aangezien UEFI zijn eigen mini-OSje is is het uiteraard kwetsbaar net als volledige OS'en. Zolang de UEFI code klein en auditable is is het nog te doen, maar dat is dus niet het geval. En dat is welbeschouwd waanzin, want UEFI is de eerste code die draait op de machine. Als die compromised is kun je de rest van de machine afschrijven qua veiligheid -- zelfs als je bijvoorbeeld ijzersterke onafhankelijke encryptie in je bootcode verwerkt hebt kan die via de eerder geladen UEFI code gewoon op losse schroeven gezet worden. Je kunt zeggen wat je wil over BIOS, maar dat was door zijn beperkingen (en grotere verscheidenheid aan implementaties) gelijk een stuk moeilijker om in een exploit om te smeden.

Nice job, Intel. Fijn dat we van dat ouderwetse BIOS af zijn.

[Sandor_Clegane]

Dit draait op de Vpro laag? Ik kan me nog een presentatie van Intel herinneren waarin ze dit uit de doeken deden en vol trots vertelden hoe geweldig het wel niet was.

Toen ik vroeg waarom ze zoiets wilden doen en dat het een niveau van aanval is waarvan zelfs het OS niet weet dat het uitgevoerd wordt ( laag dieper ) vonden ze dat maar een rare opmerking.

Well here you go.

[latka]

😀 ook mijn ervaring. De tactiek die daarna ging gebruiken: als er tijdens een leverancierspresentatie een moeilijke vraag wordt weggewuifd dan moet je het mijden als de pest.

[Verwijderd]

v3 = *(VOID **)(CommunicationBuffer + 0x20);

// eerste * is een dereference
// tweede * is een pointer naar een void
// derde * is een pointer naar een pointer naar een void ? Dat is iets wat verwarrend.

v4 = CommunicationBuffer;
*(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);

Voor niet c gebruikers iets wat verwarrende code, niet zeker of ik het goed begrijp, maar pascal achtige zou het er ongeveer zo uit zien:

v3 := ^pointer( longword(CommunicationBuffer) + $20);

of toch niet ?

Hmmm...

[albatross]

En die System Management Mode, daar zouden we sowieso eens vanaf moeten. Een soort NSA tool, die op een gebruikers CPU niet aanwezig hoort te wezen. En dus kennelijk ook door anderen misbruikt kan worden.

[Reactie gewijzigd door albatross op 23 juli 2024 08:11]

[mutley69]

Waarom moest per sé die bios verdwijnen? Secure boot en UEFI waren beter - juist. Waarom heeft het zo lang geduurd - het is nog complexer dan een bios.
Nu secure boot en uefi kunnen op de schijf staan - en kunnen dus zelfs met de voorziene beveiligingsmethodes omzeild worden. Ook dat wisten we al.
Soms is vooruitgang achteruitgang - en daar moeten we gewoon leren mee leven - die bugs raken er wel uit. Ook na 10 jaar en langer kan je last hebben van bugs uit het verleden - zie maar naar bugs in low-level protocollen.
Leren mee leven - ook wat je moet aanvaarden is - dat je een pc koopt maar er niet meer de baas over bent - en met de pda's en smartphones en tablets is 't nog veel erger.
En hoera - ook UEFI is een van de tools die aan vendor-lock-in kan meehelpen!
Wie dat niet wil - gaat naar zelfbouw - raspberry pi en consoorten. De verkoopscijfers spreken voor zich.

[beerse]

Iets is nooit beter zonder nadere omschrijving. De boot-code die ooit in de 8-bits computers zat, die was op zijn mannier ook beter: Hoe minder er in zit, hoe overzichtelijker. Maar ja, de software in de huidige boot-roms is uiteindelijk vaak groter dan de complete boot-code en basic interpreter die in Comodore-64 en msx machines zit.

Het 'beter' zijn van efi en uefi ten opzichte van de good-old bios is vooral de toegenomen functionaliteit. En dat is net zoals met de operatingsystems en programma's: Meer functies == meer complexiteit == meer mogelijkheden, ook voor hakken en breken.

[SomerenV]

Fouten graag melden in Geachte Redactie

[Verwijderd]

Eigenlijk zou er onder elk artikel een linkje naar Geachte Redactie moeten staan. Nu moet je elke keer weer denken/zoeken waar dat ook weer is..

[Blokker_1999]

Je bedoelt zoals dat linkje in de lijn onder de titel met de benaming "Feedback"?

[Verwijderd]

Tjemig, haha, moet ik zeker al meer dan 1000x hebben gezien en toch valt nu pas het kwartje, nb op een maandag ochtend

[henk1994]

Er staat boven het artikel altijd een linkje met 'Feedback' zodat je naar de Geachte Redactie ga.

[da_PSI]

Er staat "feedback" boven alle articles .. klik daar en ga

[ArmEagle]

Als reactie op de anderen, maar zo blijft het mooi onder elkaar staan;

Een foutje is snel gespot. Maar om dan te achterhalen of iemand anders daar al eerder voor in het verzameltopic, of in een eigen thread over gepost heeft, ben je al snel 5 minuten verder. Daarom heb ik al vaak genoeg de moeite niet genomen.

Wat zou het toch handig zijn als opmerkingen automatisch per post verzameld werden. En als de 'Feedback' link ook meteen een overzicht van andere opmerkingen op die post zou weergeven. Een schaduw-thread. Dan een simpele hele lichte issue-tracker voor de moderators die gewoon opmerkingen af kunnen vinken. Presto.

[Blokker_1999]

Er is een duidelijk topic met de naam " Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 44 " dat ook nog eens gepinned staat. Dat geeft niet veel verwarring en als je achteraan kijkt (door op laatste te klikken) dan zie je direct of diezelfde fout al gemeld is geweest (en zelfs als je dat niet nagaat is er nog altijd geen kwaad gebeurd als je het nogmaals post).

[ManIkWeet]

Maandag ochtend