peter green wrote:
Commons seems to be a target for such an attack. Upload is easy, although I'm not to sure about the damage potential. I suppose if an administrators account would get compromised an applet could be manufactured to mass delete content or mass block users.
If commons is vulnerable all wikimedia wiki's are and there is nothing that local commons users or admins can really do about this. Mediawiki should probablly be modified to check for garbage on the end of image files if it does not already do so.
Sending this on to wikitech-l so the devs can comment on it.
Replied on commons-l and fixed for default MediaWiki installations in r39203.
-- Tim Starling
Tim Starling wrote:
Replied on commons-l and fixed for default MediaWiki installations in r39203.
-- Tim Starling
Note that by forbidding zip based files, you're also blocking openoffice ones. Wouldn't be preferable to look for clearer jar signs, such as the presence of a manifest?
Platonides wrote:
Tim Starling wrote:
Replied on commons-l and fixed for default MediaWiki installations in r39203.
-- Tim Starling
Note that by forbidding zip based files, you're also blocking openoffice ones. Wouldn't be preferable to look for clearer jar signs, such as the presence of a manifest?
I made a jar just now with no manifest file, it worked just fine. I suppose you'd have to bundle a complete Zip file parser, like the one in PEAR, and then use it to search the directory for *.class files.
The hard part is working out exactly how Java works, so that you can match its algorithm in pure PHP. It's not going to be fast or pretty.
-- Tim Starling
On Tue, Aug 12, 2008 at 11:07 AM, Tim Starling tstarling@wikimedia.org wrote:
[snip]
The hard part is working out exactly how Java works, so that you can match its algorithm in pure PHP. It's not going to be fast or pretty.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This being said, is a major performance impact worth it? How real a threat is this; is it _currently_ being exploited?
-Chad
On Tue, Aug 12, 2008 at 7:17 PM, Chad innocentkiller@gmail.com wrote:
This being said, is a major performance impact worth it? How real a threat is this; is it _currently_ being exploited?
That's a pretty poor standard to use. If it's known to be *possible* for someone to steal large numbers of admins' cookies and/or passwords through some phishing scheme, it's of secondary concern whether anyone happens to be doing it at the moment.
Currently it's not possible, just because all ZIP uploads are blocked. This is of kind of suboptimally low granularity, is the problem. JAR really has no mandatory distinctive headers or anything?
On Tue, Aug 12, 2008 at 7:32 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:17 PM, Chad innocentkiller@gmail.com wrote:
This being said, is a major performance impact worth it? How real a threat is this; is it _currently_ being exploited?
That's a pretty poor standard to use. If it's known to be *possible* for someone to steal large numbers of admins' cookies and/or passwords through some phishing scheme, it's of secondary concern whether anyone happens to be doing it at the moment.
Currently it's not possible, just because all ZIP uploads are blocked. This is of kind of suboptimally low granularity, is the problem. JAR really has no mandatory distinctive headers or anything?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I moreso mean that until it's identified as being a major vulnerability, is taking a major hit to performance an acceptable hit to take?
If this _isn't_ a huge concern, maybe a slower look at a solution that doesn't hit performance as bad could be considered.
I'm not the one to do it, as I'm way in over my head. Just trying to keep an eye on the practical side of it.
-Chad
On Tue, Aug 12, 2008 at 7:54 PM, Chad innocentkiller@gmail.com wrote:
I moreso mean that until it's identified as being a major vulnerability, is taking a major hit to performance an acceptable hit to take?
1) I'm pretty sure it's already identified as a major vulnerability (assuming you consider XSS major).
2) I don't think allowing the vulnerability is on the table, at least not for Wikimedia. The slowdown would be for those who wanted to accept ZIP files, not for those who wanted to avoid the vulnerability -- the vulnerability is avoided regardless. (Unless you hack around and remove the blacklisting of application/zip, admittedly, which some will inevitably do, but then it's their decision as to acceptability of whatever, not ours.)
On Tue, Aug 12, 2008 at 8:03 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:54 PM, Chad innocentkiller@gmail.com wrote:
I moreso mean that until it's identified as being a major vulnerability, is taking a major hit to performance an acceptable hit to take?
- I'm pretty sure it's already identified as a major vulnerability
(assuming you consider XSS major).
- I don't think allowing the vulnerability is on the table, at least
not for Wikimedia. The slowdown would be for those who wanted to accept ZIP files, not for those who wanted to avoid the vulnerability -- the vulnerability is avoided regardless. (Unless you hack around and remove the blacklisting of application/zip, admittedly, which some will inevitably do, but then it's their decision as to acceptability of whatever, not ours.)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
You've convinced me. Sorry for the misunderstanding.
-Chad
Hello all,
Is it possible to change wiki page layout?
ex: I want to remove watch tab and add new tab that adds new page.
Thanks,
Tim Starling wrote:
I made a jar just now with no manifest file, it worked just fine. I suppose you'd have to bundle a complete Zip file parser, like the one in PEAR, and then use it to search the directory for *.class files.
The hard part is working out exactly how Java works, so that you can match its algorithm in pure PHP. It's not going to be fast or pretty.
-- Tim Starling
:( That's the problem with so generic file formats. it's easy to treat them, but hard to tell apart.
Note that the check for PK\x05\x06 is quite weak, all these legitimate files on commons contain those four bytes :) (although not on last 65558 bytes)
*BCChickadee_platform.jpg *Carboxysome.png *Opelbad.jpg *Jin_Mao_Tower_and_Shanghai_World_Financial_Center.jpg *Katzs.jpg *AntoniaGerstackerUltraCover-1.jpg *Berncastel_Burg_Landshut_1900.jpg *Fountain_The_Kissing_Students_10.jpg *Cricket_Pavilion_of_Sandbach_School.JPG *Barrow_Alaska_(2).jpg *Sakura_01.jpg *Villandry5.jpg *Montelbaan_Tower_Amsterdam.jpg *Beverly_Hillbillies_Episode_13_Home_For_Christmas.ogg *Sodra_lanken_vv_3.jpg *2008-07-12_North_Carolina_Mutual_Life_across_NC_147.jpg *JREast-Shin-misato-station-platform.jpg *BETTA_FLASH_20080704_Japan_Expo_037.jpg *Paulo_S├®rgio_Passos.jpg *Tanja_200mm.jpg *Civil_aviation_authority,_Prague_Ruzyn─ø.jpg *IC_2000_(zehn_Wagen),_cropped,_20080330Y222a.jpg *2008-08-01_Dead_turtle_at_Brier_Creek_Reservoir_1.jpg *Aachen,_Pontstra├ƒe.jpg *Schenck_Wiesbaden_099.jpg *Monument_inside_the_Temple_of_Horus_Edfu_977.PNG *Haworthia_papillosa_(4).jpg *Advance-3-06.jpg *JRW_kuchiba_sta.jpg *Pauly-Wissowa_V,1,_0055.jpg *SashaGreyEroticaLA08.JPG *Petits_fours_C.jpg *Ruth_Glacier_2.jpg *Diana_Gurtskaya,_Georgia,_Eurovision_2008,_final_02.jpg *Oriskany_July_2008_-48.jpg *Bootshafen_Voelkermarkt.JPG *Dobromierz_DolnySlask.jpg
Platonides wrote:
Tim Starling wrote:
I made a jar just now with no manifest file, it worked just fine. I suppose you'd have to bundle a complete Zip file parser, like the one in PEAR, and then use it to search the directory for *.class files.
The hard part is working out exactly how Java works, so that you can match its algorithm in pure PHP. It's not going to be fast or pretty.
:( That's the problem with so generic file formats. it's easy to treat them, but hard to tell apart.
Note that the check for PK\x05\x06 is quite weak, all these legitimate files on commons contain those four bytes :) (although not on last 65558 bytes)
Check for PK\x05\x06 on last 65558 bytes (fast), then check with a complete Zip parser (slow).
wikitech-l@lists.wikimedia.org