Jump to content

Darling Brody

Resident
  • Posts

    18
  • Joined

  • Last visited

Posts posted by Darling Brody

  1. @Coffee Pancake - Retiring LSO entirely would break all content from the first 10 years of SL.  It will unfairly impact the most loyal Residents and Creators who have been here the longest and spent the most money in SecondLife!

    @Quistess Alpha / @Rolig Loon -  Larger scripts on vehicles and avatars can hinder region crossings and teleports, with the later known to kill mono scripts to the point they need to be replaced, or repaired with a LSO auto-repair script.  The problem is related to the amount of memory that needs to be allocated in the new region for both vehicle scripts and those worn by the avatar. Taking off scripts or using LSO in the vehicle has been the only thing that fixes the problem.

    @Fenix Eldritch - From what I can see LL are not adding the new functions to LSO & MONO.  In the wiki all the new functions are mono only and have been this way for years. https://wiki.secondlife.com/wiki/Category:LSL_Functions

    I would be fine if all the new data types and functions were mono-only and LSO was left with its original behavior and functionality. LSO only needs to support the legacy code written in it so that creators can recompile LSO to maintain it in situations where mono is less desirable.  Perhaps a first step might be to make the LSO/MONO checkbox into an Advanced menu option that is off by default.  So those of us who are maintaining legacy code can turn it on when needed.

  2. There are some behavior differences in LSO and MONO which might break content with some examples in this link under VM Detection. I am sure there are many more undocumented gotchas too. https://wiki.secondlife.com/wiki/LSL_Hacks.

    LSO scripts also seems to be less likely to break due to things like the "log out due to failed teleport bug", which makes them perfect to build a self repair platform from.  I have several products that have a little LSO script in them that reboots broken mono scripts.  Of course this shouldn't be something we need to add, but it is until some long standing bugs are fixed.  Given that LL are not adding new functions to LSO I can't imagine it creates a lot of extra work to maintain, and I would rather they spend the time swatting some long standing bugs rather than re-coding the viewer and regions to take something away which might send the rest of us scampering to fix stuff for years to come.

    All that said, it will only really effect long suffering creators who were around before MONO, and probably has some advantage in making server code smaller.  I'd support it if it meant scripts would start working the moment an object is rezzed.  Scripts used to start instantly until a couple of years ago when a bugfix introduced a lag into newly rezzed scripts. That is the biggest scripting issue I have been waiting for LL to fix.  It makes simple things impossible or requires laggy workarounds where temp-rez objects need to be pre-rezzed so their scripts are running, just in case they are needed.

  3. Hi Oz,

    Thank you for that code snippet.  It is similar to what I already do.  I encrypt the messages with a pre-shared key in a very similar way.

    The reason I had to implement a check that the message was coming from SL was because of all the permissions exploits that permitted no-mod scripts to be opened, thus compromising any shared secrets and encryption keys.   While I am not aware of any active exploits that can still force open a no-mod script, it is something I would like to be able to protect against just in case a new exploit is accidentally created.  Back in 2009'ish someone deleted my entire customer database after compromising the permissions on one of my customer registration scripts to obtain the encryption key I use to communicate with the server.

    Here is what I was defending against in detail:-

    • Someone cracks open my script with a permission exploit and copies my shared secret, thus allowing them to send my server correctly encrypted messages.
    • They discover I am also checking against the owner of the prim to reject messages from prims that are not owned by me, so they send the message from outside SL with a fake value loaded into HTTP_X_SECONDLIFE_OWNER_KEY.
    • This is where knowing the message comes from SL where they cant fake headers is very important, as I can reject messages from outside SL that may contained spoofed headers.

    If there is every another active permission exploit to open scripts how do we protect our servers?

    Suggestions?

     

  4. On 6/9/2020 at 3:24 AM, Oz Linden said:

    It has come to our attention that some users may be validating that the returned URLs are in the domain they expect, presumably by matching them against something like 'sim.*\.agni\.lindenlab\.com'. These checks may have been inspired by simulator bugs that at one time or another have caused URLs to be returned that didn't work because some part of the domain name was missing.

    Two Issues that may be related to this that need consideration for in-world and off-world validation & security:-

    1) In-World

    Vending machines and product upgrade delivery scripts need to filter out requests coming from the beta grid and other invalid sources to make sure people are not spending beta grid money to get stuff delivered to their main grid accounts without paying.

    With email we have >> The prim's email address is its key with "@lsl.secondlife.com" appended, llGetKey() + "@lsl.secondlife.com"

    With HTTP_Request() we have >> string llGetHTTPHeader( key request_id, string header );  -- With a result like h ttps://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322

    This will need to be maintained or else you will have a repeat of the HUGE content theft/exploitation issues we had 10 years ago that drove away so many content creators. ( BTW my content from that time is STILL being passed around for free )

     

    2) Off-World

    Also off-world servers need to make sure a request is coming from a secondlife domain and not some other external source. (Read: attempted hack)

    For example: in PHP you might use something like this to ensure all requests are coming from SecondLife's main grid.

        ///////////////////////////////////////////////////////////////
        //
        // Validate origin was SL main grid
        //
        $hostname = gethostbyaddr($_SERVER['REMOTE_ADDR']); // extract domain/grid information
        if (substr($hostname, strlen($hostname) - 18, strlen($hostname)) != "agni.lindenlab.com")
        {
            die("ERROR: Request not from Main Grid!"); // ignore requests that are not from the main SL grid
        }

     

    Without the above test you can not trust other values returned such as $_SERVER['HTTP_X_SECONDLIFE_OWNER_KEY'] because you can not be sure the origin was seconldlife and not someone spoofing the values.

     This is one of the most critical layers that must be maintained.

    Darling Brody

×
×
  • Create New...