Unauthorized access

Anyone on the planet can send an email, unauthorized users, bots, scripts, anything can target an smtp address if its known, this can result in spam or worse, a denial of service (DOS) attack.

1. Make the smtp address is only resolvable inside a corporate network. This rules out external users

2. Set a JEMH Profile > Allowlist > Allowlist of regexps matching valid senders (see Email Forgeries)

Email Forgeries

Anyone with a suitable routing mail server can initial email and present any sender address they like. This Effectively sets the remote users email address to mimic another user, potentially internal, with elevated security. Email is inherently insecure.

1. Intermediary email routing may perform validation of domains, but can't be guaranteed.

2. Signed email can fix email forgeries, but, not all users use common formats. JEMH has limited support for GPG, and has yet to support SMIME standards for email signing.

Privilege Escalation

In general, anyone can combine the above two attacks to craft emails that will pass default JIRA mail handler and JEMH message checks, allowing comments or attachments to be added to issues.

There is no mitigation currently. Emails are taken at face value, if the sender is 'userx@domain.com' then the email is processed as that user, comments and attachments are created and attributed to that user.

Directive abuse

JEMH support Directives, a way to update any field on a JIRA issue that can be updated. Anyone who can edit issues can edit fields. JEMH Directives can be used for this in unexpected ways if it is enabled

1. Disable Directives (they are off by default)

2. Enable Directives only during Create for initialization purposes only

3. Set a strict whitelist of Directives that are enabled (JEMH Profile > Directives > Whitelisted Directives)

4. Currently no user-level whitelisting has been written (JEMH-1185)

Mailbombs

Suitably crafted emails can result in out of memory problems causing a DOS scenario

1. JEMH has limits in place for content size related processing, preventing runaway commenting on issues, and limiting the amount of data that can be added to an issue. This stops OutOfMemory problems accessing an issue with more MB of content than JIRA is running in.

2. Whitelisting attachments by type is possible by type (in the Profile > Attachments section), blacklisting problem types, eg .zip, .tar, .tar.gz or more is possible.

3. Attachments can be completely turned off by email.

Unauthorized Profile Changes

A user can defeat any profile level security setting

1. JEMH has declarative security for web-based administrative functions covering configuration of JEMH Profiles. JEMH configuration requires an Administrator privilege, i.e. is dependant on JIRA security, the security of the server etc.

2. Various undocumented REST API's exist to facilitate real time updates and dynamic web interaction, each of these has validation check in place:

   1. The authenticated user is logged in

   2. The authenticated user is an admin

Unauthorized use of AdHoc Notifications

Anyone authorized to use JEMH AdHoc Notifications can by nature set an arbitrary recipient, as well as set the from: address details.

1. Current versions 1.5.70+ contain security settings for AdHoc notifications, controlling their use at a global level, but offering a per-project override.

2. Setting the sender requires the address selected to be validated by the mailserver. Open relay mail servers are generally bad, and corporate network admins should strictly limit what email any application, eg, JIRA, can send 'from'.

See Use Adhoc Notifications

DOS due to webaccess

Any interaction with JIRA can trigger all related addons to re-evaluate license status, in some cases, this load can result in a DOS.

JIRA user-facing UI features that trigger licensing checks are:

• JEMH NotificationHistory

• JEMH AdHoc notifications

1. JEMH Configuration is filtered, so any related checks require the user to be logged in as an admin before getting to JEMH admin features

2. Licensing checks for general user-facing UI features currently cache license status for 10 minutes.

3. Owing to the more advanced nature of permissions for AdHoc notifications, all project permissions are cached on access, and flushed every 5 minutes (to cause project settings to be refreshed).

4. Notification History requires the logged in user to be able to BROWSE_ISSUE

5. AdHoc notification configuration at project level require project admin/system admin in order to use.