Külföldi torrent oldalak Orpheus | OPS | Apollo A most unfortunate set of circumstances

A témát ebben részben 'Torrent oldalak hírei' CF dealer hozta létre. Ekkor: 2025. február 04..

  1. CF dealer / Tulajdonos Vezetőségi tag

    Csatlakozott:
    2011. június 15.
    Hozzászólások:
    24,562
    Kapott lájkok:
    2,283
    Beküldött adatlapok:
    0
    Nem:
    Férfi
    Lakhely :
    deutschland
    Hangjelzés a Chaten:
    nem
    People who were online yesterday received the surprise of seeing various sensitive site configuration values in place of the expected website. How that happened was a perfect storm of circumstances, that have been addressed to avoid it from happening in the future, and all the exposed values have been rotated. No user data was at risk at any time.

    Here is the post mortem of the incident.

    To understand it all, we have to go back a number of years and begin with the original what.cd Gazelle codebase. The architecture for setting up configuration variables back then was rather cumbersome and awkward to maintain. As I recall, it was a plain text file of key/value pairs and it was quite easy to make errors when making changes. And it probably meant that a lot of developers who worked on Gazelle at the time found it easier to just hard-wire the number they needed, where they needed it, rather than make them easy to reconfigure.

    One of the changes we made years ago was to change the configuration data to a PHP file, so that the interpreter would catch errors as soon as it was loaded. If there was an error, the site would show a white screen of death. After this, it became easy to pull out a lot of magic numbers from the code and turn into (documented!) configuration variables.

    The next problem encountered was that it was cumbersome to keep separate the default values required to bring up a site, and the values a specific site needs (like database passwords). Another change was made to address this, in that the default configuration file would be "good enough" for most needs, here or elsewhere, and only a small number of variables would need to be overridden to tailor behavior for any given site.

    Fast forward to a third issue we ran into, where a misconfiguration on the front end proxy would dump the PHP code of the main page of the site. So that part of the site was also revamped to show only require gazelle.php; on a page if something went wrong.

    And then we get to a fourth problem. In revamping that code, I ran into what I had remembered as being a termed a Gate Problem, which, in the literature, goes by the name of a Chesterston Fence.

    G. K. Chesterton was a philosopher and in regards to the economics of political reform, formulated the following parable:
    There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”In relation to Gazelle, there was a pair of statements at the beginning and end of a large section of code that had the effect of saying "if anything wants to output stuff to the page in this section... just throw it away". And when I refactored the code, I did not think hard enough about its use and how anything could like that could happen, and removed the two statements.

    And then there is a final situation that was needed to align with the rest, the blame of which belongs to PHP itself. PHP is a funny language, in that, by default, it assumes somewhat paradoxically that a file you want it to execute does not contain any PHP code. It assumes the file is text, perhaps HTML, and must be sent to the browser. To instruct PHP that, yes, there is actually PHP code to interpret, the source code file must contain "<?php" From that point on, the PHP interpreter will interpret the rest of the file as php code. No other language behaves this way.

    And finally we get to yesterday. I was working on a merge request in the CI which will change the names of a couple of configuration variables in the override file. As I looked them up, I noticed an old key belonging to retired code that no longer serves any purpose. So I deleted it, as there is no point keeping obsolete code present.

    And this is where we get to the crux of the matter. I was working in the CI and not looking at the site, and for reasons I will never fathom, I managed to move to the top of the file and repeat the operation, deleting the first line. After that, first line no longer had the opening "<?php" and the interpreter faithfully dumped it to the browser, which I missed completely.

    And as a result, a series of sensitive configurations were posted at the top of the page. Sensitive in that yes, if one had access to the server, you could log into the database and exfiltrate any amount of data. But there was never any risk of that. The backend server is so heavily firewalled off that even if you knew the server address, scanning it would reveal no open services, no means of purchase to get inside. There were also some internal network addresses that reveal little, and some other minor things like exact ids of wiki pages. Since then, all of the sensitive values have been reset to new values. At no time was any personal data like email addresses or announce keys ever in danger of being exposed. And yes, the bit of code that loads the configuration file now has the safeguard code back in place to prevent it from ever again being spewed out by accident.

    The biggest visible consequence of this (apart from having to log in anew) is that we have pushed forward with the planned changes to RSS feeds. Now you will definitely need to update your feed addresses to get new data, as the internal signature key value was changed and the old URLs no longer work.

    And so all of that is why we took the site down: to change what needed to be changed, and update what needed to be updated. My humble apologies. This, at least, will not happen again.

    Discuss this post here