Gallery Down?
-
- Elite
- Posts: 1454
- Joined: Sun Jan 12, 2003 6:24 pm
- Location: Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy
- Contact:
Gallery Down?
The image-gallery is down.
Somebody else recognized this?
PS: how about a developer/modelling-gallery where one can put pics of his (unfinished) ships, screenshots (not ingame), etc ... ? (EDIT:maybe with the forum account-login)
Pontiac
Somebody else recognized this?
PS: how about a developer/modelling-gallery where one can put pics of his (unfinished) ships, screenshots (not ingame), etc ... ? (EDIT:maybe with the forum account-login)
Pontiac
Last edited by pontiac on Wed May 07, 2003 8:53 pm, edited 1 time in total.
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
crap this thing is falling apart faster than we can build it up :-X
anyone know why this happened? perhaps some idiot figured out how he could delete it
anyone know why this happened? perhaps some idiot figured out how he could delete it
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Bounty Hunter
- Posts: 128
- Joined: Fri Jan 03, 2003 4:51 pm
- Location: Somewhere in the Multiverse
- Contact:
Well, you're running 1.3.3, which is the latest version. As far as I know there haven't been any exploits reported for that version.
Also, Gallery doesn't stick blobs in db tables (v2 is supposed to have db support when it comes out), so it's not a database issue.
So, what could it be?
Well, first of all, Gallery does depend on some files to contain the meta-data, and I have had a problem once or twice with the file albums.dat getting corrupted.
First thing to do is check to see if that directories with the photos and the two resized images (thumbnail and display) are still intact. If they are, then it's a meta-data thing. Unfortunately, I'm not really sure if there is a way to fix a corrupted albums.dat. The way I've fixed it before is simply to copy over the albums.dat from backup, but that made me lose whatever meta-data happened since the backup.
Also, Gallery doesn't stick blobs in db tables (v2 is supposed to have db support when it comes out), so it's not a database issue.
So, what could it be?
Well, first of all, Gallery does depend on some files to contain the meta-data, and I have had a problem once or twice with the file albums.dat getting corrupted.
First thing to do is check to see if that directories with the photos and the two resized images (thumbnail and display) are still intact. If they are, then it's a meta-data thing. Unfortunately, I'm not really sure if there is a way to fix a corrupted albums.dat. The way I've fixed it before is simply to copy over the albums.dat from backup, but that made me lose whatever meta-data happened since the backup.
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
gone?
I did a search for jpgs and gifs on the site and there aren't any from the gallery.
I do have a backup of albums from January 15 (including all the .dat files) but I don't know if it is worth copying them back...
I do have a backup of albums from January 15 (including all the .dat files) but I don't know if it is worth copying them back...
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
I'm thinking "local exploit" here
SF.net allows *anyone* to get a user account
and programs have so many local holes over the years that I'm sure they're infested with people who think they have root privaledges
there appears to be other collateral damage to the folders that not even I would have permission to delete....
someone with r00t must have some ire they wish to lash out...which is really a shame because we've not ever told users to "get lost" or something when they come here with a problem or a question
SF.net allows *anyone* to get a user account
and programs have so many local holes over the years that I'm sure they're infested with people who think they have root privaledges
there appears to be other collateral damage to the folders that not even I would have permission to delete....
someone with r00t must have some ire they wish to lash out...which is really a shame because we've not ever told users to "get lost" or something when they come here with a problem or a question
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
Maybe the forum problems are related, but it's not likely. And I don't see why anyone would want to trash our pics or forums.
Well, there don't seem to be any way to get the images back from the website.
does any one here have a more recent backup than January, or will we lose all of those pretty screenshots that people ahve taken so much effort to take?
Well, there don't seem to be any way to get the images back from the website.
does any one here have a more recent backup than January, or will we lose all of those pretty screenshots that people ahve taken so much effort to take?
-
- Daredevil Venturer
- Posts: 583
- Joined: Sun Feb 16, 2003 12:58 am
- Location: West Coast of USA
- Contact:
-
- Site Administrator
- Posts: 478
- Joined: Thu Jan 02, 2003 10:05 am
- Location: Perth, Western Australia
- Contact:
k here is my idea... we all pitch in a bit of money and then get hosting from some place that gives unlimited bandwidth + space. Cos sourceforge is getting a bit 'unsafe' as we seem to have noticed. Either that or we complani to sourceforge management that our project is getting screwed around with regularly.
Which one do you people think? The hosting option, if we all used the donate button to give say $5 of our local currency, would give more than enough for a years hosting...
But before we do anything like that, could somebody give me a rough estimate of our total bandwidth/data usage, or is there somewhere on sourceforge you can get that? Cos if we were going to buy hosting we would need to know this...
anyways
Which one do you people think? The hosting option, if we all used the donate button to give say $5 of our local currency, would give more than enough for a years hosting...
But before we do anything like that, could somebody give me a rough estimate of our total bandwidth/data usage, or is there somewhere on sourceforge you can get that? Cos if we were going to buy hosting we would need to know this...
anyways
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
about 1/6 of the downloads for 0.3.0 came from the *wrong* website, costing Sourceforge 96 GB of bandwidth.
so multiply that by 6 and you have 600 GB of data... almost half a terrabyte?
is that right?
100 ,000,000* 10,000 = 1 TB
that means it only takes 10,000 downloads to make a terrabyte
next release will use at least that much
so multiply that by 6 and you have 600 GB of data... almost half a terrabyte?
is that right?
100 ,000,000* 10,000 = 1 TB
that means it only takes 10,000 downloads to make a terrabyte
next release will use at least that much
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Site Administrator
- Posts: 478
- Joined: Thu Jan 02, 2003 10:05 am
- Location: Perth, Western Australia
- Contact:
-
- Site Administrator
- Posts: 1089
- Joined: Thu Jan 02, 2003 10:07 am
- Contact:
Actually if you were to move the homepage, that dose not mean that you would have to move the compiled binaries. You could still keep them on SourceForge, and if someone deletes them I guess we will get a beta build early. However I do agree that the site should be moving off SF. Taking a look at some of the other popular SF projects, they have done the same. As for the bandwidth, I am not sure how much we are currently using per month, but I would guess less then 1GB/1000MB just for the Forums and Gallery, Wiki and Manual and not including binaries
I had a friend refer this link to me http://www.hugehost.com/
I had a friend refer this link to me http://www.hugehost.com/
I know you believe you understand what you think I said.
But I am not sure you realize that what you heard is not what I meant.
Wing Commander Universe Forum | Wiki
Wing Commander: The Wasteland Incident
But I am not sure you realize that what you heard is not what I meant.
Wing Commander Universe Forum | Wiki
Wing Commander: The Wasteland Incident
-
- Site Administrator
- Posts: 478
- Joined: Thu Jan 02, 2003 10:05 am
- Location: Perth, Western Australia
- Contact:
-
- Star Pilot
- Posts: 7
- Joined: Wed Jan 08, 2003 10:50 am
- Location: Karlsruhe, Germany
-
- Site Administrator
- Posts: 1089
- Joined: Thu Jan 02, 2003 10:07 am
- Contact:
I will look into this weekend. I need to figure out how much real bandwith is being used for the site, and not the binaries.
I know you believe you understand what you think I said.
But I am not sure you realize that what you heard is not what I meant.
Wing Commander Universe Forum | Wiki
Wing Commander: The Wasteland Incident
But I am not sure you realize that what you heard is not what I meant.
Wing Commander Universe Forum | Wiki
Wing Commander: The Wasteland Incident
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
ace_123 has restored much of the image database
it's a shame that the most recent pictures weren't on the last backup, but it's better than nothing
it's a shame that the most recent pictures weren't on the last backup, but it's better than nothing
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Bounty Hunter
- Posts: 128
- Joined: Fri Jan 03, 2003 4:51 pm
- Location: Somewhere in the Multiverse
- Contact:
Busy busy busy. Too busy to play any games or read forums. Now I'm not so busy and I've got something to say about this.
Really, there should be no reason to move from sf.net. The cost for bandwidth alone would be too much, and as long as sf.net is willing to absorb that cost, I would definately stay with them.
As for the local exploit, while that may be possible (I've never had a sf.net shell, so I have never audited their security), I don't think that is what happened. My first thought on both the forums and then the gallery are exploits in the PHP code.
There are thousands of cross-site and cross-browser scripting errors in thousands of PHP and PERL packages. I know that the maintainers of Gallery are diligent about fixing things that they find or which are brought to their attention, but that doesn't mean that some hacker hasn't figured out a way to mess with it and just hasn't told anyone yet. Also keep in mind that there is a Java based client for Gallery, "Gallery Remote", and it's possible that someone has found a way to exploit that. Or maybe they just figured out the password.
As for the forums...well, pretty much the same deal, except that I know that phpBB gets a lot of attention from the script kiddie community because it's a popular package. This site is running v2.0.3, and v2.0.4 has been out since January. From the Changelog at:
http://www.phpbb.com/documents.php?mode=changelog
I see that there is a HUGE list of updates and fixes, and some which catch my eye are:
Fixed cross-browser scripting issue with highlight param
Fixed database utilities failing to backup data with MySQL
Fixed possible cross-site scripting issue with username search
Fixed potential SQL vulnerability with marking of private messages
Any of which is reason enough to upgrade...
Some may recall my warning when the first edition of the VS phpBB forums went live, that if you are going to run phpBB (or any forum really) you MUST keep up with the latest version. And even then, you are only protected from the exploits which have already been published and addressed...rest assured, new ones will be discovered.
phpBB uses MySQL, but Gallery doesn't (not until 2.0 anyway), so I strongly doubt we are looking at a database issue.
No, the very limited nature of the problems leads me to strongly suspect URL based attacks. A local root compromise would almost certainly have resulted in much more damage, and/or a glory page replacing the homepage. A cracker who has root would likely just delete the whole gallery subdir, rather than bothering with picking out just the images and deleting them, and the same goes for the forums. A sophisticated cracker might do something handy like embedding a zombie client into the downloadable files, but if they were that good, then they certainly wouldn't do anything noticable to the system, as that could indicate that they were there, and real crackers try very hard to leave no muddy bootprints on the doorstep.
As for backing up, why not just use rsync and every day (or every few hours) backup the changed data to some box outside of sf.net? Rsync is very fast, and if there is a problem, it's simply a matter of syncing back the other way, and possibly running a fix/optimize on the restored db tables. Simple, and it's just a script running under cron.
Really, there should be no reason to move from sf.net. The cost for bandwidth alone would be too much, and as long as sf.net is willing to absorb that cost, I would definately stay with them.
As for the local exploit, while that may be possible (I've never had a sf.net shell, so I have never audited their security), I don't think that is what happened. My first thought on both the forums and then the gallery are exploits in the PHP code.
There are thousands of cross-site and cross-browser scripting errors in thousands of PHP and PERL packages. I know that the maintainers of Gallery are diligent about fixing things that they find or which are brought to their attention, but that doesn't mean that some hacker hasn't figured out a way to mess with it and just hasn't told anyone yet. Also keep in mind that there is a Java based client for Gallery, "Gallery Remote", and it's possible that someone has found a way to exploit that. Or maybe they just figured out the password.
As for the forums...well, pretty much the same deal, except that I know that phpBB gets a lot of attention from the script kiddie community because it's a popular package. This site is running v2.0.3, and v2.0.4 has been out since January. From the Changelog at:
http://www.phpbb.com/documents.php?mode=changelog
I see that there is a HUGE list of updates and fixes, and some which catch my eye are:
Fixed cross-browser scripting issue with highlight param
Fixed database utilities failing to backup data with MySQL
Fixed possible cross-site scripting issue with username search
Fixed potential SQL vulnerability with marking of private messages
Any of which is reason enough to upgrade...
Some may recall my warning when the first edition of the VS phpBB forums went live, that if you are going to run phpBB (or any forum really) you MUST keep up with the latest version. And even then, you are only protected from the exploits which have already been published and addressed...rest assured, new ones will be discovered.
phpBB uses MySQL, but Gallery doesn't (not until 2.0 anyway), so I strongly doubt we are looking at a database issue.
No, the very limited nature of the problems leads me to strongly suspect URL based attacks. A local root compromise would almost certainly have resulted in much more damage, and/or a glory page replacing the homepage. A cracker who has root would likely just delete the whole gallery subdir, rather than bothering with picking out just the images and deleting them, and the same goes for the forums. A sophisticated cracker might do something handy like embedding a zombie client into the downloadable files, but if they were that good, then they certainly wouldn't do anything noticable to the system, as that could indicate that they were there, and real crackers try very hard to leave no muddy bootprints on the doorstep.
As for backing up, why not just use rsync and every day (or every few hours) backup the changed data to some box outside of sf.net? Rsync is very fast, and if there is a problem, it's simply a matter of syncing back the other way, and possibly running a fix/optimize on the restored db tables. Simple, and it's just a script running under cron.