Megosztás a következőn keresztül:


MCCP puffervédelem

A Windows Vista rendszertől kezdve az RPC-rendező motor további lépéseket tesz annak érdekében, hogy megakadályozza az ügyféloldali puffertúlcsordulásokat a visszaadott adatok miatt. Ezt a létesítményt Mini Compute Conformance Protectionnek (MCCP) nevezzük.

Ha az ügyfél egy meglévő pufferre mutató mutatót ad át egy [ki] vagy [,ki] paramétert, a rendszer az adott paraméter visszaadott adatait a meglévő pufferbe másolja. Ha a visszaadott adatok nagyobbak, mint az átadott puffer, puffertúlcsordulás fordulhat elő, ha az RPC a visszaadott adatokat a túl kicsi pufferbe másolja. Lásd: Top-Level és beágyazott mutató.

Az MCCP-vel az RPC megpróbálja észlelni ezt a feltételt, és elutasítja a hívást, ha észleli. Ha a visszaadott adatok nem felelnek meg a megadott pufferméretneksize_is, akkor a rendszer elutasítja a hívást, és RPC_X_BAD_STUB_DATA kivétel keletkezik. A nem módosított sztringek esetében a rendszer elutasítja a hívást, ha a meglévő sztring mérete (a null terminátorig) nem elegendő a visszaadott sztring tárolásához, a hívás elutasításra kerül. Az RPC nem képes észlelni a puffertúllépéseket minden körülmények között, ezért a fejlesztőnek ajánlott a puffertúllépésekkel szembeni szokásos óvintézkedéseket megtennie.

Ha az ügyfél nem ad át meglévő puffert egy [ki] paraméterhez, hanem halasztott mutatót ad át NULL, az RPC a szokásos szabályokat követi egy új puffer lefoglalásához az ügyfél nevében. Ez a puffer a visszaadott adatok tárolásához elegendő tárterülettel lesz lefoglalva.

A második védelem az, hogy a korrelált paraméterek esetében az RPC kényszeríti a nemnull puffer átadását, ha a korrelációs szám változó nemnull.

HRESULT PassString( [in] DWORD Length, [in, unique, string, size_is( Length )]LPWSTR MyString );

Ha MyString null , az RPC elutasítja a hívást, kivéve, ha Hossz értéke 0. Vegye figyelembe, hogy az RPC lehetővé teszi, hogy Hossz 0 legyen, míg a MyString nemNULL, az RPC pedig a MyString 0 hosszúságú pufferfoglalásként kezeli.