Misuse of feature in PKP OCS 2.3.6

Software Support
1

Hi,

Had installed and setup pkp ocs 2.3.6 with recommended patches on RHEL 6.8.

Yesterday, we found that, a user created an account and in the bio statement (Edit profile) used the file upload feature and uploaded an image file which contained a message “hacked by xxx”.

As per the standard configuration, the file was uploaded in public/site/images/user directory and though as per my knowledge it is not a hack, but a way to create panic. As public directory is part of web root, if this is shared with people, it will be assumed as though web site running pkp ocs is hacked.

I think the feature of uploading file should be disabled or the file uploaded here should be stored in non-web root directory. But, this may make the image uploaded invisible next time the user tries to see his/her existing profile.

Your recommendations please.

2

Hi @athavale.anant,

OCS permits limited uploads of image files by non-administrator users – there’s no hack here. We likely will be changing this feature in future releases of OMP/OJS for other reasons, but will likely not change it in OCS 2.x.

Regards,
Alec Smehcer
Public Knowledge Project Team

3

Hi, @asmecher

Thanks. But, the concern here is a kind of panic situation. Is there a way to disable file upload feature (image) for a non-administrator user completely?

4

Hi @athavale.anant,

The panic is unwarranted – but if you want to disable that feature, edit plugins/generic/tinymce/TinyMCEPlugin.inc.php and remove jbimages from the plugin list (there are 3 references to it). Then remove lib/pkp/lib/tinymce/jscripts/tiny_mce/plugins/jbimages and its contents. Finally, review the images in the public/site/images (and subdirectories) and remove anything you don’t like the look of.

[Edit: For current releases of OJS and OMP, the relevant place to find jbimages references is in lib/pkp/js/controllers/SiteHandler.js. If you’re using minified javascript (see config.inc.php) you may need to rebuilt the Javascript after editing. Or, to be expedient, edit js/pkp.min.js to remove references to jbimages there too.]

Regards,
Alec Smecher
Public Knowledge Project Team

5

Thanks. Will try to implement.

6

Hi @athavale.anant,

If you get the chance, can you clarify why this is a source of such concern? I don’t think this is anything substantially different from the features available in e.g. Drupal or Wordpress for user profile image uploads.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi @asmecher,

I agree from one view that, this should not be a concern.

But, any update done should not be part of web root so that, it is not accessible without authentication on the website. Here in this case, by posting an image of a type which was not expected and spreading the link on social media/mail to create unnecessary negative impact for a hosting organisation could have been avoided.

Sometimes, we need to be bold. One option could have been to remove the image from conference site and continue with existing setup. But, this may result in further damaging the site with uploads of similar sort of images and further propagation through social media/mails.

Anyway, thanks for your concern.

Just wanted to know, what if similar images are uploaded on Drupal/Wordpress user profile pictures? What will site owner will do? He will let the images be there?

Anant.

8

Hi @athavale.anant,

Agreed that this is a misuse of an OCS feature, I’m just trying to find out whether/why there are sysadmin expectations for the software to behave differently (i.e. a reason to change the software, rather than to clean up the unwanted images).

There’s no way for the software to programmatically distinguish between a valid e.g. profile and an image containing a “defaced by” message, so one option would obviously be to remove the ability to upload these images entirely (as documented above), but I would argue that it’s not worth removing a useful feature because of a misleading claim (by the person who uploaded the image) of a server vulnerability.

I would like to move the public files area into the purview of the private files area, for other reasons – but because we’re ensuring that uploaded images are in fact images, it doesn’t really have any impact on security.

The reason I raise Drupal and Wordpress is that, like OJS, I believe they store image files somewhere within the web root.

Regards,
Alec Smecher
Public Knowledge Project Team

9

Hi there,

Your instructions disable the editor’s (tinymce) ability to upload images.

However the user can still upload a single profile image as there is an input file field called “Profile Image” in the “Edit Profile” page. In order to disable this functionality, the “templates\user\profile.tpl” file must be edited and the following code must be removed or commented:

> <tr valign="top">
> 	<td class="label">
> 		{fieldLabel name="profileImage" key="user.profile.form.profileImage"}
> 	</td>
> 	<td class="value">
> 		<input type="file" id="profileImage" name="profileImage" class="uploadField" /> <input type="submit" name="uploadProfileImage" value="{translate key="common.upload"}" class="button" />
> 		{if $profileImage}
> 			{translate key="common.fileName"}: {$profileImage.name|escape} {$profileImage.dateUploaded|date_format:$datetimeFormatShort} <input type="submit" name="deleteProfileImage" value="{translate key="common.delete"}" class="button" />
> 			<br />
> 			<img src="{$sitePublicFilesDir}/{$profileImage.uploadName|escape:"url"}" width="{$profileImage.width|escape}" height="{$profileImage.height|escape}" style="border: 0;" alt="{translate key="user.profile.form.profileImage"}" />
> 		{/if}
> 	</td>
> </tr>
10

Hi @nafens,

That’s a separate feature, but if you want to disable that too, I’d suggest also removing the back end code supporting it. Just removing that markup from the front end won’t stop the feature from being used e.g. if someone is using an automated form posting bot.

Note that neither feature is being used for a server incursion – it appears that “attackers” are simply uploading an image legitimately, then claiming that as a successful attack. You might as well claim that uploading an image to imgur.com is a successful defacement of that site.

Regards,
Alec Smecher
Public Knowledge Project Team

11

Hi @asmecher,

I totally agree with you that uploading a “hacked by” image as a profile avatar does not constitute defacement or hacking.

I just posted this in order to help out the original poster who seems to want to eliminate any kind of image misuse and the only way to do this is to disable all user image uploads.

And you are right, removing the back end code is necessary too as the “attackers” are usually using automated upload scripts that bypass user form input.

12

Hi @asmecher,

I made the code changes in tinymce 3 times and removed lib/pkp/lib/tinymce/jscripts/tiny_mce/plugins/jbimages.

Actually Where is these codes ? what I want to make changes ?

Thanks in Advance.

13

Hi @asmecher,

I am waiting for your response for the above query.

Thank you

14

Hi @sonbabyjohn,

Please be patient – we are a small team. It may take a few days or more to respond to a question.

To remove the back-end code that handles user profile image uploads, remove all references to uploadProfileImage. You haven’t specified which of our applications you’re using or what version, but in OJS 3.x, these appear in:

  • lib/pkp/classes/user/form/PublicProfileForm.inc.php
  • lib/pkp/controllers/tab/user/ProfileTabHandler.inc.php
  • lib/pkp/templates/user/publicProfileForm.tpl

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
15

Sorry @asmecher, usually you respond to the queries very fast. Very sorry and I will keep in mind for future.

We are using OJS 2.4.8.0. Can you mention where all uploadProfileImage is mentioned in this version.

Once again thank you for the continues support.

16

Hi @sonbabyjohn,

You can find references to uploadProfileImage in OJS 2.4.x in:

  • classes/user/form/ProfileForm.inc.php
  • templates/user/profile.tpl
  • pages/user/ProfileHandler.inc.php

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
18

We at the University of North Texas Libraries appreciate the guidance given in this thread for disabling the feature to upload images. While we understand PKP’s position that this is not an actual hacking, our problem is that the pranksters do this on our site and then alert our state-level agency of the “hack”, which then gets our IT team in trouble. In terms of staff time spent on this, it doesn’t really matter that no true hacking takes place.

Furthermore, we worry that someone could use this backdoor to share illegal content online by creating users and uploading profile photos.

So we very much support having a setting for site administrators that disables the ability to upload profile photos on all journals on an OJS site. That way every time we upgrade OJS, we won’t need to redo the code hacks described below.

Please let me know if I can provide any additional info to help justify this feature request.

19

Hi @kshawkin,

It might be enough to disable image hotlinking for image URLs matching the pattern of profile pictures; see How do I prevent image hotlinking? – DreamHost Knowledge Base for a walk-through on how to accomplish this using a .htaccess file.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
20

So to be clear, the advantage of this to one of the PHP code changes described above is that the fix would persist across versions of OJS (unless a future version of OJS changes where the profile images are stored)?

21

Hi @kshawkin,

It means you can leave the profile image feature functional, but it tells your web server to direct access via a different web page or directly from e.g. an email client to another image of your choosing. Users can still upload arbitrary profile images (as they should be able) but it prevents their display in other contexts. It also means you won’t have to carry modifications through the upgrade process – just the standard .htaccess file.

Regards,
Alec Smecher
Public Knowledge Project Team