He is basically saying that the exploits Nathaniel found and reported have only been fixed in Valve's main titles. He hasn't found or reported a new exploit. I think it has been mentioned by KyleS on one or multiple of these mailing lists that these exploit fixes should be ported onto other branches. Apparently that has not been done?

On 03.09.2015 22:06, N-Gon wrote:
Someone give this man an unusual Finder's Fee

On Thu, Sep 3, 2015 at 3:59 PM, Refeek Yeglek <[email protected] <mailto:[email protected]>> wrote:

    Hi, I'm one of the developers for Team Fortress 2 Classic, a
    source mod project. Recently, someone abused a bug present in
    Source SDK 2013 MP to distribute viruses to quite a few of our
    players and developers. The way they did it was by abusing a spray
    exploit present in the SDK 2013 MP edition to upload a file
    pretending to be a spray to all players and executing it. The
    technical info on how it works from one of our other coders will
    be posted at the end of this email, but here's what you need to
    know as a server owner:

    We don't know how many source games are vulnerable. The big name
    VALVe ones aren't, but any sourcemod probably is. This includes
    ones on steam like Fortress Forever, or Fistful of Frags.

    If you're running a server for a non-VALVe or bigname(Titanfall,
    GMOD, etc.) Source Engine game, then here's what you need to do:

    1. Set sv_upload to 0 on your server.

    2. If you are a TF2C server host, shut your server down and start
    scanning your server for viruses.

    3. Pester valve to fix this ASAP.

    TL;DR:
    Sprays can be exploited to run code on people's systems and break
    into accounts, we've had quite a few CS:GO and TF2 items lifted
    from accounts and moved to trade alts and disappearing after that.
    Disable sprays ASAP if you host a sourcemod multiplayer server.

    Here's the technical info for how stuff works:

    "The vulnerability is triggered by a missing check to see if a
    memory allocation succeded in the loading of VTFs. When the
    material is loaded, there is space allocated for the material. The
    crucial option in the using of this exploit is the option to skip
    Mipmaps from the material. If, for instance, the first mipmap is
    skipped, the game will copy the mipmap data to buffer + size of
    first mipmap. When the memory allocation fails, the buffer will be
    0, because thats what malloc returns on out of memory. This means,
    that the only factor determining where the block is put is
    determined by the size of the first mipmap. This way you can put
    the data in the second mipmap whereever you want, meaning you can
    write to a predictable location in memory. This is additionally
    encouraged due to the fact that ASLR is disabled for the module in
    question. From that point on ROP is used to mark a controlled
    memory location executable and transfer control to it, bypassing
    DEP. The distribution of the malicious material file can be easily
    done through the use of the spray system, which uploads a custom
    material to the server and distributes it. This is of course not
    the only way to distribute it, but one used in this case. This is
    not absolutely accurate and technical details have been left out
    due to them not influencing this exploit."

    _______________________________________________
    To unsubscribe, edit your list preferences, or view the list
    archives, please visit:
    https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds




_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Reply via email to