Hukommelse væltede ud i 18 år: Udbredt Office-program kompromitterede sig selv

Jeg forstår ikke hvorfor der dukker eksekverbar kode op i en datafil som en Access-fil jo er.

Access er så gammelt et program at man sikkert skrev sin egen malloc() og boostede performance lidt mere på en 11 MHz Intel 286 ved ikke at cleare allokeret memory.

Det fungerede og så er 'ms-malloc()' måske bare "blevet siddende" gennem alle opdateringer og forbedringer?

ja, jeg har læst dig indlæg hvor du redegjorde for hvorfor du syntes små fejl er ligegyldige, det var derfor jeg lavde mit indlæg hvor jeg forklarede af nok små fejl pludselig bliver til et alvorligt sikkerhedshul.

Men så må du nok til at fortælle hvordan du mener dette kan blive et stort sikkerhedshul. Men i øvrigt mener jeg ikke små fejl er ligegyldige. De skal naturligvis fikses. Men jeg mener ikke de behøver blæses op på forsiden af alverdens medier. Så kunne vi bruge alt vores tid på at læse om sikkerhedshuller der pt. er ligegyldige. Men fikses skal de selvfølgeligt.

Men som jeg også redegjorde for i samme indlæg,

ja, jeg har læst dig indlæg hvor du redegjorde for hvorfor du syntes små fejl er ligegyldige, det var derfor jeg lavde mit indlæg hvor jeg forklarede af nok små fejl pludselig bliver til et alvorligt sikkerhedshul.

Det kan godt være du anser det som en dum lille fejl, men hvis der er nok små dumme fejl der sættes sammen, så er det netop af man kan hacke en computer bare ved af der bliver åbnet en Access fil

Men som jeg også redegjorde for i samme indlæg, så er der meget langt til at dette bliver et reelt problem. Fordi der er meget andet der skal ske før at dette kan bruges til noget.

Selvfølgeligt er det dumt at skrive mere eller mindre tilfældige dele af hukommelsen på disken.

Netop, og derfor skal Access ikke gøre det.

Det kan godt være du anser det som en dum lille fejl, men hvis der er nok små dumme fejl der sættes sammen, så er det netop af man kan hacke en computer bare ved af der bliver åbnet en Access fil

Jeg kan ikke finde MDB andre steder end i kommentarer.
Jeg kan ikke finde nogen bagvedliggende artikel som V2 refererer til, og linket til Microsoft er uspecifikt. Har du link til moderartiklen?

Her:

https://www.mimecast.com/blog/2020/01/mimecast-discovers-mdb-leaker-microsoft-access-vulnerability-cve-2019-1463/

Der er også CVE-id etc.

Der er således ikke noget problem hvis man "importerer online data" som du skrev.

Det er muligt, jeg prøvede bare at forklare at MS Access ikke længere er et fuldstændig stand alone isoleret system - derimod kan det interagere med andre systemer og også "det verdensomsændende Indernet".

Jeg kan ikke finde MDB andre steder end i kommentarer. Jeg kan ikke finde nogen bagvedliggende artikel som V2 refererer til, og linket til Microsoft er uspecifikt. Har du link til moderartiklen?

Nej, det er meget mere generelt (iøvrigt hedder accessfiler ACCDB nu):

Men som jeg læser beskrivelsen af problemet, så er det kun MDB filer hvor der kan dukke kode op på denne måde. Der er således ikke noget problem hvis man "importerer online data" som du skrev.

Jo ... men er det MDB filer der bliver udvekslet? For det er kun sidde som indeholder kode sådan som jeg læser historien.

Nej, det er meget mere generelt (iøvrigt hedder accessfiler ACCDB nu):

• Excel
• Text
• XML
• ODBC
• SQL-server
• Azure DB (?)
• HTML-dokument (!)
• Outlook-folder
• Dynamics 365 (?)
• Salesforce (?)

F.eks. har jeg prøvet at bruge "sharepoint lists" som datalager (RO/RW) - en afdeling kan f.eks. vedligeholde en liste på intrawebbet med sharepoint selv (intraweb) eller access, og en anden afdeling kan trækkke den liste på bla. samme måder eller med excel. Jeg har selv lige hentet firmaets lecacy it systems liste ind i access på den måde. Jeg har også prøvet at bruge min egen liste som data storage (en af deres anbefalinger ved split af singlebruger-database til fler-bruger-accessdatabaser).

Access er en desktop database. Den har databasen liggende lokalt (i denne sammenhæng er netværksdrev også lokale) og indenfor det paradigme er den sikker. (...) Såfremt man ønsker et andet paradigme så må man vælge noget andet (Fx. SQL server).

Det er jo netop det man kan: Med få klik lave en super hurtig (cost effective) GUI til tabeller i f.eks. en MSSQL-database, i stedet for at få kodefolk til at kode en GUI.

Dog har f.eks. Access 2016 mulighed for at importere online data, så hvis man benytter en online dataprovider så vil den potentielt være sårbar overfor angreb herfra.

Jo ... men er det MDB filer der bliver udvekslet? For det er kun sidde som indeholder kode sådan som jeg læser historien.

Access' design er jo grundlæggende usikkert idet frontend (GUI) og backend (data) er i samme lokale fil. Man kan dog adskille front og backend (det har jeg gjort), og f.eks. bruge en MSSQL eller en Sharepoint som datalager.

Access er en desktop database. Den har databasen liggende lokalt (i denne sammenhæng er netværksdrev også lokale) og indenfor det paradigme er den sikker. På samme måde som min teksteditor også er designet til at redigere filer på min harddisk. Såfremt man ønsker et andet paradigme så må man vælge noget andet (Fx. SQL server).

For det første skal man have adgang til filsystemet på computeren der kører Access. Dvs. det er ikke tilfældige brugere på nettet der kan udnytte dette hul.

Tak for svar; jeg er overvejende enig. Dog har f.eks. Access 2016 mulighed for at importere online data, så hvis man benytter en online dataprovider så vil den potentielt være sårbar overfor angreb herfra.

Som jeg læser artiklen bliver den eksekverbare kode dog ikke loaded ind og kørt, så derfor er det som du skriver et meget begrænset problem.

Access' design er jo grundlæggende usikkert idet frontend (GUI) og backend (data) er i samme lokale fil. Man kan dog adskille front og backend (det har jeg gjort), og f.eks. bruge en MSSQL eller en Sharepoint som datalager.

Der må da virkelig være sjusk i deres mem-håndtering hvis den ikke holder data og kode skarpt adskilt?

Databaser kam jo have tabeller med blob's, så i princippet kunne Access jo gemme noget kode i databasen.

Selvfølgeligt er det dumt at skrive mere eller mindre tilfældige dele af hukommelsen på disken. Men såfremt det blot er kode, så er det her et meget meget lille problem. Såfremt der også kan ryge data ud (fx. passwords) så er det et lidt større problem (men kun ganske lidt).

For det første skal man have adgang til filsystemet på computeren der kører Access. Dvs. det er ikke tilfældige brugere på nettet der kan udnytte dette hul.

For det andet: Hvis man først har adgang til filerne, så kan man læse alt hvad der står i dem (fx. password hashes). Det er således meget meget begrænset hvad man vil vinde ved at kunne se data.

For det tredie: Ja, angrebet giver viden om address randomization. Men address randomization skifter hver gang programmet startes og sådan som Access typisk bruges så kører programmet ikke i dagevis. Brugeren starter Access på sin desktop og lukker det ned når han ikke skal bruge det mere.

For det fjerde: Selv hvis man har viden om address randomization, så mangler de stadigvæk at påvise en måde hvor man kan lave buffer overflow. Uden dette er der intet hul. Address randomization er et eksempel på "defence in depth" hvor penetrering af et sikkerhedsniveau ikke giver adgang fordi der stadigvæk er andre sikkerhedsbarrierer man skal igennem.

"Defence in depth" er muligvis det mest oversete sikkerhedskoncept og et af de mest værdifulde. Se fx. på cloud computing: Der kan min kode køre på samme CPU som andres kun adskilt af CPU'en memory manager (=manglende defence in depth).

Alas, denne sag er historien om en fjer der blev til fem høns.

Jeg forstår ikke hvorfor der dukker eksekverbar kode op i en datafil som en Access-fil jo er. Der må da virkelig være sjusk i deres mem-håndtering hvis den ikke holder data og kode skarpt adskilt?

Hvis det ikke er tilsigtet så handler det jo bare om en pointer der peger på det gale. Man har både pointere der peger på kode og pointere der peger på data, så det er en relativ nem fejl at lave (fx. en uinitializeret variabel). Det overraskende er at det ikke har crashet Access hele tiden men der har Microsoft åbenbart været heldige/uheldige (alt efter hvilken vinkel man ser fra) eller også var det tilsigtet.

Hej Dennis. Du har ret, så jeg har rettet artiklen igennem. En anden gang må du gerne sende korrekturforslag og lignende per mail, så vi ikke får mudret kommentarsporet til :)

Tak for opmærksomheden! Mvh

Jeg forstår ikke hvorfor der dukker eksekverbar kode op i en datafil som en Access-fil jo er. Der må da virkelig være sjusk i deres mem-håndtering hvis den ikke holder data og kode skarpt adskilt?

https://en.m.wikipedia.org/wiki/Data_segment

Normalt bliver jeg pænt irriteret når der bliver selvopfundet danske udgaver af engelske ord, bare fordi man synes at det skal være et dansk ord... Men i det her tilfælde er "memory -> hukommelse" helt almindeligt. Hvorfor ikke bruge det?