Dela via

Säkerhetsbulletin

Microsoft Security Bulletin MS02-030 – Måttlig

Omarkerad buffert i SQLXML kan leda till kodkörning (Q321911)

Publicerad: 16 juni 2002 | Uppdaterad: 28 februari 2003

Version: 1.1

Ursprungligen publicerad: 12 juni 2002

Uppdaterad: 28 februari 2003

Sammanfattning

Vem bör läsa den här bulletinen: Systemadministratörer som använder Microsoft® SQL Server™ 2000.

Sårbarhetens inverkan: Två säkerhetsrisker, varav den allvarligaste kan köra valfri kod för angriparen.

Högsta allvarlighetsgrad: Måttlig

Rekommendation: Systemadministratörer som har aktiverat SQLXML och aktiverat datafrågor via HTTP bör installera korrigeringen omedelbart.

Programvara som påverkas:

  • Microsoft SQLXML, som levereras som en del av SQL Server 2000 och kan laddas ned separat.

Allmän information

Teknisk information

Teknisk beskrivning:

SQLXML möjliggör överföring av XML-data till och från SQL Server 2000. Databasfrågor kan returneras i form av XML-dokument som sedan enkelt kan lagras eller överföras. Med SQLXML kan du komma åt SQL Server 2000 med hjälp av XML via webbläsaren via HTTP.

Det finns två säkerhetsrisker i SQLXML:

  • Ett okontrollerat buffertsårbarhet i ett ISAPI-tillägg som i värsta fall kan tillåta att en angripare kör valfri kod på IIS-servern (Microsoft Internet Information Services).
  • En säkerhetsrisk i en funktion som anger en XML-tagg som kan göra det möjligt för en angripare att köra skript på användarens dator med högre behörighet. Ett skript kan till exempel köras i intranätzonen i stället för i Internetzonen.

Förmildrande faktorer:

Avmarkerad buffert i SQLXML ISAPI-tillägget:

  • Administratören måste ha konfigurerat en virtuell katalogstruktur och namngivning som används av SQLXML HTTP-komponenterna på en IIS-server. Säkerhetsrisken ger ingen möjlighet för en angripare att hämta katalogstrukturen.
  • Angriparen måste känna till platsen för den virtuella katalogen på den IIS-server som har konfigurerats specifikt för SQLXML.

Skriptinmatning via XML-tagg:

  • För att ett angrepp ska lyckas måste användaren ha behörighet på SQL Server.
  • Angriparen måste känna till adressen till den SQL Server där användaren har behörighet.
  • Angriparen måste locka användaren till en webbplats under deras kontroll.
  • Frågor som skickas via HTTP är inte aktiverade som standard.
  • Microsofts metodtips rekommenderar att du inte tillåter ad hoc-URL-frågor mot databasen via en virtuell rot.
  • Skriptet körs i användarens webbläsare enligt den IE-säkerhetszon som används för att ansluta till IIS-servern som är värd för SQLXML-komponenterna. I de flesta fall är detta intranätzonen.

Allvarlighetsgrad:

Avmarkerad buffert i SQLXML ISAPI-tillägget:

Internetservrar Intranätservrar Klientsystem
Microsoft SQLXML-version som levereras med SQL Server 2000 Gold Medel Medel Ingen
Microsoft SQLXML version 2 Medel Medel Ingen
Microsoft SQLXML version 3 Medel Medel Ingen

Skriptinmatning via XML-tagg:

Internetservrar Intranätservrar Klientsystem
Microsoft SQLXML-version som levereras med SQL Server 2000 Gold Medel Medel Ingen
Microsoft SQLXML version 2 Medel Medel Ingen
Microsoft SQLXML version 3 Medel Medel Ingen

Ovanstående utvärdering baseras på de typer av system som påverkas av sårbarheten, deras typiska distributionsmönster och den effekt som sårbarheten skulle ha på dem. Kritiskheten beräknas på grund av möjligheten att fjärrköra kod i säkerhetskontexten för operativsystemet och möjligheten att köra skript på en användares system med förhöjd behörighet.

Sårbarhetsidentifierare:

Testade versioner:

Microsoft testade den ursprungliga SQLXML-versionen med SQL Server 2000 Gold samt SQLXML version 1, 2 och 3 för att bedöma om de påverkas av den här säkerhetsrisken. SQLXML version 1 stöds inte längre och bör uppgraderas till en senare version enligt beskrivningen i vanliga frågor och svar nedan.

Vanliga frågor och svar

Vilka säkerhetsrisker elimineras av den här korrigeringen?
Den här korrigeringen eliminerar två säkerhetsrisker som påverkar SQLXML, en komponent som gör det möjligt för SQL Server 2000-servrar att acceptera databasfrågor via XML och skicka resultatet via XML. Säkerhetsriskerna finns i SQLXML HTTP-komponenterna.

Vad är XML?
XML (Extensible Markup Language) kan ses som ett universellt dataformat för överföring av information på Internet. Med hjälp av XML kan webbprogram som körs på olika leverantörers maskinvaru- och programvaruplattformar, och som skrivits på olika programmeringsspråk, utbyta data med varandra. XML är ett viktigt verktyg för att göra det möjligt för webbtjänster att fungera sömlöst med varandra. Ett företag kanske till exempel vill erbjuda sina anställda möjlighet att hantera sin löneinformation och spåra sin semestertid via en enda webbportal, även om de två typerna av data kan finnas på servrar som implementerades på helt olika maskinvaru- och programvaruplattformar. Så länge utvecklarna av respektive system har standardiserats på XML som dataformat kan de enkelt göra detta.

Vad är SQLXML?
Bland de många typer av data som kan överföras via XML finns databasfrågor och databassvar. SQLXML gör det möjligt för SQL Server 2000 att bearbeta XML-databasfrågor och skapa XML-databassvar och, om det är konfigurerat för att göra det, fungera via HTTP. SQLXML överbryggar klyftan mellan XML och relationsdata. En första version av SQLXML levererades som en del av SQL Server 2000 Gold, och senare versioner har gjorts tillgängliga för nedladdning från Microsoft Developers Network.

Vilka ÄR SQLXML HTTP-komponenterna?
SQLXML kan användas för att utbyta XML-data med en SQL-server med någon av flera olika kommunikationsmetoder. En av de kommunikationsmetoder som kan användas av SQLXML är Hyper-text Transmission Protocol (HTTP), som använder Internetprotokoll för att överföra information SQLXML HTTP-komponenterna konfigureras i en virtuell katalog på en IIS-server, som kan finnas på samma dator som SQL Server eller på en separat dator.

Vad är en virtuell katalog?
Innan du kan komma åt SQL Server 2000-databasen med HTTP måste administratören konfigurera en virtuell katalog. Administratören använder verktyget IIS Virtual Directory Management för SQL Server för att definiera och registrera en ny virtuell katalog, även kallad den virtuella roten, på den dator som kör IIS. Det här verktyget instruerar IIS att skapa en association mellan den nya virtuella katalogen och en instans av Microsoft SQL Server. Information om användargränssnittet för det här verktyget finns i IIS Virtual Directory Management Utility. När du använder SQLXML HTTP-funktioner måste namnet på IIS-servern och den virtuella katalogen anges som en del av URL:en. Informationen i den virtuella katalogen (inklusive inloggnings-, lösenords- och åtkomstbehörigheter) används för att upprätta en anslutning till en specifik databas och köra frågan.

Är SQLXML HTTP-komponenterna aktiverade som standard?
Nej. Innan du kan komma åt SQL Server med hjälp av en URL via webbläsaren eller någon HTTP-klient måste administratören först konfigurera en virtuell katalog för SQL Server på IIS-servern. Administratören använder snapin-modulen SQLXML Microsoft Management Console (MMC) som har tillhandahållits med någon av SQLXML-versionerna. SQLXML HTTP-komponenterna kan inte konfigureras med IIS-verktyg.

Är SQLXML tillgängligt för SQL Server 7.0?
Nej. Den är bara tillgänglig för SQL Server 2000.

Vilka är de sårbarheter som påverkar SQLXML?
Det finns två säkerhetsrisker:

  • En säkerhetsrisk som kan göra det möjligt för en angripare att köra valfri kod på IIS-servern.
  • En säkerhetsrisk som kan göra det möjligt för en angripare att köra skript i systemet för en användare som hade åtkomst till en påverkad SQL-server.

Omarkerad buffert i SQLXML ISAPI-tillägget (CVE-CAN-2002-0186)

Vad är omfånget för den första sårbarheten?
Det här är en säkerhetsrisk för buffertöverskridning. En angripare som har utnyttjat den här säkerhetsrisken kan få fullständig kontroll över en berörd databasserver. Detta skulle ge angriparen möjligheten att lägga till, ta bort eller ändra data på servern, formatera om hårddisken eller vidta andra åtgärder. Säkerhetsrisken kunde bara utnyttjas om administratören hade konfigurerat och aktiverat SQLXML HTTP-komponenterna på en IIS-server.

Vad orsakar sårbarheten?
Sårbarhetsresultatet beror på att SQLXML ISAPI-tillägget innehåller en omarkerad buffert i ett avsnitt som hanterar datafrågor via HTTP.

Vad är ISAPI?
ISAPI (Internet Services Application Programming Interface) är en teknik som gör det möjligt för webbutvecklare att skriva anpassad kod som tillhandahåller nya tjänster för en webbserver. Sådan kod kan implementeras i någon av två former:

  • Som ett ISAPI-filter – ett dynamiskt länkbibliotek (.dll) som använder ISAPI för att svara på händelser som inträffar på servern.
  • Som ett ISAPI-tillägg – ett dynamiskt länkbibliotek som använder ISAPI för att tillhandahålla en uppsättning webbfunktioner utöver de som tillhandahålls internt av IIS.

När det gäller den här säkerhetsrisken är den berörda koden ett ISAPI-tillägg som gör att SQLXML kan kommunicera med användare via HTTP.

Vad är det för fel med SQLXML ISAPI-tillägget?
Tillägget innehåller en omarkerad buffert. Om en databasbegäran som tas ut via HTTP är felaktigt formaterad på ett visst sätt, skulle det få till följd att bufferten överskrids.

Hur kan en angripare försöka utnyttja den här sårbarheten?
Sårbarheten kan utnyttjas av alla som kan upprätta en HTTP-session med en berörd IIS-server som är värd för SQLXML-komponenterna.

Vad skulle den här säkerhetsrisken göra det möjligt för en angripare att göra?
Beroende på specifika data som angriparen har valt kan någon av två effekter inträffa:

  • Om data valdes slumpmässigt skulle IIS-processen misslyckas.
  • Om data har valts noggrant kan det vara möjligt för angriparen att ändra ISAPI-tillägget när det kördes.

Vad skulle krävas för att återställa normal drift om angriparen tillhandahöll slumpmässiga data?
IIS-servern som är värd för SQLXML HTTP-tjänsterna måste startas om.

Vad kan den ändrade processen göra om angriparen angav noggrant valda data och ändrade ISAPI-tillägget?
Den ändrade processen skulle kunna vidta alla åtgärder som angriparen dirigerade den till. SQLXML ISAPI-tillägget körs med LocalSystem-privilegier, så angriparen kan få fullständig kontroll över servern och vidta alla önskade åtgärder på den.

Du sa ovan att sårbarheten bara kan utnyttjas om angriparen kan upprätta en HTTP-session med servern. Vad skulle behöva hända för att detta ska vara möjligt?
Först måste administratören aktivera SQLXML. Som standard är den inaktiverad. För det andra måste SQLXML konfigureras för att tillåta kommunikation via HTTP. SQLXML ISAPI-tillägget finns bara om detta har gjorts. Även när SQLXML är aktiverat är aktivering av HTTP-kommunikation ett separat konfigurationssteg. Slutligen skulle angriparen behöva direkt anslutning till servern. Det är troligt att det senare steget i de flesta fall bara skulle vara möjligt i ett intranätscenario. Databasservrar, även de som är webbaktiverade, är vanligtvis inte direkt anslutna till Internet. I allmänhet skulle en klientwebbserver mellanlag vara mellanliggande mellan Internetanvändare och databasservern, vilket hindrar angriparen från att upprätta en webbsession och utnyttja sårbarheten. I de flesta fall är det enda scenariot där en användare skulle kunna upprätta en session med en sådan server i ett intranätscenario.

Hur eliminerar korrigeringarna den här sårbarheten?
Korrigeringarna eliminerar säkerhetsrisken genom att införa korrekt bufferthantering i ISAPI-tillägget.

Hur vet jag om jag kör SQLXML?
Om du kör SQL Server 2000 och har aktiverat SQLXML HTTP-komponenterna på en IIS-server bör du installera korrigeringen.

Det finns tre olika korrigeringar. Vad behöver jag installera?
Det beror på vilken version av SQLXML du använder. SQL Server 2000 levereras med en första version av SQLXML, så du bör minst installera korrigeringen för SQL Server 2000 Gold. Men det har funnits tre efterföljande versioner tillgängliga för nedladdning.

Jag vet inte vilka versioner av SQLXML jag har installerat. Hur vet jag det?
Följande visar hur du fastställer vilka versioner av SQLXML som är installerade och vilka åtgärder du bör vidta:

  • I Start-menyn på IIS-servern kontrollerar du om du har en programgrupp för "Microsoft SQL Server" som innehåller programmet "Enterprise Manager". Om du har programmet har du den version av SQLXML som levererades med SQL Server Gold installerad och bör installera korrigeringen för den versionen.

    Det finns två paket för SQLXML-versionen som levereras med SQL Server Gold. Du bör välja den version som motsvarar den version av MDAC som du använder. Kontrollera registernyckeln HKEY_LOCAL_MACHINE/Software/Microsoft/DataAccess/FullInstallVer/ och leta efter ett tal som börjar med 2.6 (för MDAC version 2.6) eller 2.7 (för MDAC version 2.7).

    Om du får ett meddelande under installationen av korrigeringen som säger att du har SQLXML version 1 bör du uppgradera till en senare version av SQLXML med hjälp av anvisningarna nedan, eftersom SQLXML version 1 inte längre stöds.

  • Sök efter Sqlvdr2.dll på IIS-servern. Om det hittas installerar du korrigeringen för SQLXML 2.0.

  • Sök efter Sqlvdr3.dll på IIS-servern. Om det hittas installerar du korrigeringen för SQLXML 3.0

Jag har fler än en av dessa versioner installerade. Vilken korrigering måste jag tillämpa?
Du måste tillämpa korrigeringen för var och en av de versioner som du har installerat.

Hur gör jag för att uppgradering från SQLXML version 1?
Den senaste versionen av SQLXML kan laddas ned från https://msdn2.microsoft.com/library/Aa286527.aspxoch kan också hittas genom att söka på https:. När du har installerat den nya SQLXML finns det ett IIS-konfigurationsverktyg som gör att du kan ange egenskaper för en virtuell katalog. Det finns en knapp för att uppgradera till den nya versionen av SQLXML, klicka på den här knappen för att slutföra uppgraderingen från SQLXML version 1.

Skriptinmatning via XML-tagg (CVE-CAN-2002-0187)

Vad är omfånget för den andra sårbarheten?
Det här är en höjning av sårbarheten för privilegier. En angripare som lyckades utnyttja den här sårbarheten skulle kunna orsaka att skript körs på en annan användares system i IE-säkerhetszonen som är associerad med IIS-servern som kör SQLXML HTTP-komponenter. Sårbarheten är föremål för ett antal viktiga förmildrande faktorer:

  • Det kunde bara utnyttjas mot en användare som hade behörighet att fråga en påverkad SQL-server.
  • Angriparen skulle behöva ha betydande information, inklusive namnet på den berörda SQL-servern
  • I de flesta fall skulle skriptet köras i intranätzonen, vilket inte har några betydande skillnader från säkerhetszonen som angriparens egen webbplats skulle placeras i.

Vad orsakar sårbarheten?
Sårbarhetsresultatet beror på att en av parametrarna som kan ingå i en XML SQL-fråga, som kallas Rot, inte verifieras korrekt. Om skriptet ingick i rotparametern som en del av en SQL-fråga skulle skriptet inkluderas i svaret från servern. Om det återges i en webbläsare körs skriptet i den IE-säkerhetszon som är associerad med IIS-servern som kör SQLXML HTTP-komponenter.

Vad är rotparametern?
Root är en parameter som kan ingå i en SQLXML-begäran för att säkerställa att frågeresultaten innehåller välformulerad XML. Det gör det genom att se till att frågeresultatet blir ett fullständigt XML-dokument med endast en enda XML-tagg på den översta nivån i frågeresultatet. Anta till exempel att ett frågeresultat normalt skulle se ut så här:

<customers customerid="ALFKI" companyname="Alfreds Futterkiste"></customers><customers customerid="ANATR" companyname="Ana Trujillo Emparedados y helados">

I vissa fall kan det faktum att det finns flera kundtaggar komplicera bearbetningen av resultatet. Genom att inkludera rotparametern kan resultatet av frågan se ut så här:

<root xmlns:sql="urn:schemas-microsoft-com:xml-sql"></root></customers><customers customerid="ALFKI" companyname="Alfreds Futterkiste"></customers><customers customerid="ANATR" companyname="Ana Trujillo Emparedados y helados">

Vad är fel med hur SQLXML hanterar rotparametern?
SQLXML bör se till att värdet för parametern inte innehåller skript. Det gör det dock inte, vilket innebär att SQLXML skulle inkludera skriptet i svaret om en XML-databasbegäran inkluderade skriptet i rotparametern. Om svaret senare renderades i en webbläsare skulle skriptet köras.

Vad skulle detta göra det möjligt för en angripare att göra?
I ett skrämmande scenario kan sårbarheten ge en angripare en möjlighet att köra skript på en annan användares system. Anta att angriparen var värd för en webbplats och kunde locka en användare att besöka den och klicka på en länk på den. Länken kan skicka en XML-fråga till en SQL-server. Om frågan innehöll skriptet i rotparametern för frågan bäddas skriptet in i det resulterande svaret från servern och skulle köras i användarens webbläsare när svaret renderades.

Vad skulle detta få angriparen? Kunde han inte bara ha kört skriptet direkt när användaren klickade på länken?
Angriparens webbsida kan ha kört skriptet direkt när användaren klickade på länken. Skriptet skulle dock köras i den IE-säkerhetszon som är associerad med angriparens webbplats (som standard Internetzonen). Med hjälp av säkerhetsrisken skulle angriparens skript köras i säkerhetszonen som är associerad med IIS-servern som kör SQLXML HTTP-komponenter.

Vilken zon skulle skriptet köras i?
Det beror på det specifika scenariot, men i de flesta fall skulle IIS-servern som kör SQLXML-komponenterna vara en intranätserver och skriptet skulle därför köras i intranätzonen. Detta skulle vanligtvis få angriparen mycket få ytterligare behörigheter. Standardinställningarna för intranätzonen är exakt desamma som för Internetzonen, med tre undantag, varav inget skulle tillåta destruktiva åtgärder:

  • Java-behörigheter. Den här inställningen är som standard "medel" i intranätzonen, men "hög" i Internetzonen
  • Få åtkomst till datakällor mellan domäner. Detta är inställt på "prompt" i intranätzonen, men "inaktivera" i Internetzonen.
  • Fråga inte efter val av certifikat när det inte finns något certifikat eller bara ett certifikat. Detta är inställt på "aktivera" i intranätzonen, men "inaktivera" i Internetzonen.

Kan angriparen utnyttja den här sårbarheten mot alla användare som besökte hans webbplats?
Nej. Angriparen kunde bara utnyttja säkerhetsrisken om allt följande var sant:

  • Användaren hade åtkomst till en IIS Server som kör SQLXML HTTP-komponenter som inte hade korrigerats.
  • Användaren hade fått behörighet av SQL-administratören att ta ut frågor på servern.
  • Angriparen kände till namnet på den virtuella katalog som har konfigurerats på IIS Server för SQLXML HTTP-komponenter. I de flesta fall skulle detta kräva att angriparen är insider i användarens nätverk.

Kan den här sårbarheten utnyttjas av misstag?
Nej. Säkerhetsrisken kunde bara utnyttjas av en angripare som skickade särskilt felaktiga data till rotparametern.

Hur eliminerar korrigeringarna den här sårbarheten?
Korrigeringarna eliminerar säkerhetsrisken genom att införa korrekt giltighetskontroll på rotparametern.

Hur vet jag om jag behöver tillämpa en korrigering?
Se avsnittet ovan.

Korrigeringstillgänglighet

Ladda ned platser för den här korrigeringen

Ytterligare information om den här korrigeringen

Installationsplattformar:

Den här korrigeringen kan installeras på system som kör SQL Server 2000 SP2

Inkludering i framtida servicepaket:

Korrigeringen för det här problemet kommer att ingå i SQL Server 2000 SP3.

Omstart krävs: Ja

Ersatta korrigeringar: Ingen.

Verifierar korrigeringsinstallation:

SQLXML-leverans med SQL Server 2000 Gold:

  • Kontrollera att korrigeringen har installerats på datorn genom att bekräfta att följande registernyckel har skapats på datorn:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Uppdateringar\DataAccess\Q321858

SQLXML version 2.0:

  • Kontrollera att korrigeringen har installerats på datorn genom att bekräfta att följande registernyckel har skapats på datorn:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Uppdateringar\SQLXML 2.0\Q321460

SQLXML version 3.0:

  • Kontrollera att korrigeringen har installerats på datorn genom att bekräfta att följande registernyckel har skapats på datorn:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Uppdateringar\SQLXML 3.0\Q320833

Varningar:

Ingen

Lokalisering:

Den här korrigeringen kan tillämpas på alla språkversioner.

Hämta andra säkerhetskorrigeringar:

Korrigeringar för andra säkerhetsproblem är tillgängliga från följande platser:

  • Säkerhetskorrigeringar är tillgängliga från Microsoft Download Center och kan hittas enklast genom att göra en nyckelordssökning efter "security_patch".
  • Korrigeringar för konsumentplattformar är tillgängliga från Webbplatsen WindowsUpdate

Övrig information:

Erkännanden

Microsoft tackar Matt Moore på Westpoint Ltd. för att ha rapporterat det här problemet till oss och arbetat med oss för att skydda kunder.

Support:

  • Microsoft Knowledge Base-artikeln Q321911 diskuterar det här problemet och kommer att vara tillgänglig cirka 24 timmar efter lanseringen av den här bulletinen. Kunskapsbasartiklar finns på webbplatsen för Microsoft Online Support .
  • Teknisk support är tillgänglig från Microsoft Product Support Services. Det kostar inget för supportsamtal som är associerade med säkerhetskorrigeringar.

Säkerhetsresurser: Webbplatsen Microsoft TechNet Security innehåller ytterligare information om säkerhet i Microsoft-produkter.

Friskrivning:

Informationen som tillhandahålls i Microsoft Knowledge Base tillhandahålls "som den är" utan garanti av något slag. Microsoft frånsäger sig alla garantier, antingen uttryckliga eller underförstådda, inklusive garantier för säljbarhet och lämplighet för ett visst syfte. Under inga omständigheter ska Microsoft Corporation eller dess leverantörer vara ansvariga för eventuella skador, inklusive direkta, indirekta, tillfälliga, följdskador, förlust av företagsvinster eller särskilda skador, även om Microsoft Corporation eller dess leverantörer har informerats om risken för sådana skador. Vissa stater tillåter inte undantag eller begränsning av ansvar för följdskador eller oförutsedda skador, så den föregående begränsningen kanske inte gäller.

Revideringar:

  • V1.0 (12 juni 2002): Bulletin skapad.
  • V1.1 (28 februari 2003): Uppdaterade nedladdningslänkar till Windows Update.

Byggd 2014-04-18T13:49:36Z-07:00</https:>