New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security Issue: Memory leak. #2314
Comments
You are a bit late, this was in 2018, I can only assume the number of leaks have gone up since then. |
XD, it's so sad to hear that. |
|
Yeah, kudos to you for finding this out though. The testing framework also seems like a helpful tool. |
I can't understand this. If the |
"DeckManager::LoadDeck" will check if the code read from dbuf[i] (4 bytes) can be found in the database or not. If it in the database, the function will add it into 'deck'; else will let 'errcode' record it. And 'errcode' will be sent back to players in the "SingleDuel::PlayerReady" function. Also, we can check our deck when we begin a game to know whether there are some dbuf[i] code the same as card ID coincidentally. |
So how does it relate to memory leak? |
When the player sent a 'CTOS_UPDATE_DECK' package with unsafe 'mainc' and 'sidec', there will be an integer overflow. And that will make function "DeckManager::LoadDeck" read 'dbuf' more then it should be. for(int i = 0; i < mainc; ++i) {
code = dbuf[i];
if(!dataManager.GetData(code, &cd)) {
errorcode = code;
continue;
}If the parameter 'mainc' is a large number, then 'dbuf[i]' can be far from '&dbuf' location. |
I see, it's talking about how to find memory leak |
|
Hi, Thanks in advance ! |
|
I would fix it now. Last time I made a PoC to set |
Memory leak
This vulnerability happened when the function "SingleDuel::UpdateDeck" and "SingleDuel::PlayerReady" been used.
When the player sends a package with error 'mainc' size and 'sidec' size, the function "SingleDuel::UpdateDeck" haven't check those parameters is legal or not. Then this function will calculate the sum of those parameters.
The algorithm thinks 'mainc' and 'sidec' are two unsigned number, so there is an integer overflow, when we set those parameters like (1, -1), their sum will be zero. It is ok though but in the function "deckManager.LoadDeck", it will cause a buffer overread.
We can see in this function, the parameters 'mainc' and 'sidec' were treat as two int type numbers. So if we set 'mainc' as '0x7fffffff' and 'sidec' as '0x80000001', in this function it will read 'dbuf' from range 0 to 2147483647.
Function "DeckManager::LoadDeck" also do a important thing: If the memory's data can be found in "dataManager.GetData" function, then it will add it into 'deck'; Else if "dataManager.GetData" function can't find memory's data in database, it will record it in the errorcode and return. Then in the "SingleDuel::UpdateDeck" function, the errorcode will be writen into 'deck_error[dp->type]'.
Now we can see the function "SingleDuel::PlayerReady".
This function will check 'deck_error[dp->type]', if it is not zero, it will pack the errcode into 'scem' structure and send it to players. Thanks to it, we can get an easy way to leak the program memory.
And here is my test program, it works well in my local environment.
https://github.com/ChinaBluecat/ygo-fuzz-frame
The text was updated successfully, but these errors were encountered: