jersey
  1. jersey
  2. JERSEY-2327

NonceManager causes permanent memory leak if clients sends milliseconds for oauth_timestamp

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.18
    • Fix Version/s: 2.6
    • Component/s: None
    • Labels:
      None

      Description

      The NonceManager.verify() method implicitly assumes the oauth_timestamp is in seconds as it multiples the inputted value by 1,000 as soon as it comes in, but the JavaDoc does not reflect this. We discovered that if the client sends oauth_timestamps in milliseconds, the underlying SortedMap tsToKeyNoncePairs will grow without bound (for 44,000 years), with the gc() never finding any elements to evict because all values are in the future. This eventually leads to OutOfMemory heap error, causing our server to crash.

      From Section 8 of the OAuth 1.0 specification: "Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests."

      The specification suggests that, although oauth_timestamp is commonly expected to be in seconds, the Service Provider may choose a different time unit, such as milliseconds. There's no clear indication in the Jersey library, though, that using milliseconds will have a disastrous effect. At the very least, the documentation for Jersey should be updated to explicitly state that the timestamp must be in seconds.

      Regardless of whether Jersey should support seconds or milliseconds for oauth_timestamp values, Jersey should be patched to prevent an incorrect or malicious client from causing the server to run out of memory. There should be a map based on System.currentTimeMillis(), rather than oauth_timestamp, that the gc() should use to evict elements from the tsToKeyNoncePairs map, so that it cannot trigger a memory leak, regardless of which clients connect to it.

        Issue Links

          Activity

          Hide
          Marek Potociar added a comment -

          We need to evaluate the issue and check if the problem is only related to Jersey 1.x code or if it also applies to Jersey 2.x impl. If the problem is only in Jersey 1.x, then target for Jersey 1.19. If also in Jersey 2.x code, we should try to address the issue ASAP.

          Show
          Marek Potociar added a comment - We need to evaluate the issue and check if the problem is only related to Jersey 1.x code or if it also applies to Jersey 2.x impl. If the problem is only in Jersey 1.x, then target for Jersey 1.19. If also in Jersey 2.x code, we should try to address the issue ASAP.
          Hide
          selikoff added a comment -

          I reviewed the source code for 1.18 and 2.5.1 and the NonceManager is unchanged between the two, save a few JavaDoc notations:

          https://jersey.java.net/project-info/2.5.1/jersey/project/oauth1-server/xref/org/glassfish/jersey/server/oauth1/NonceManager.html

          Show
          selikoff added a comment - I reviewed the source code for 1.18 and 2.5.1 and the NonceManager is unchanged between the two, save a few JavaDoc notations: https://jersey.java.net/project-info/2.5.1/jersey/project/oauth1-server/xref/org/glassfish/jersey/server/oauth1/NonceManager.html
          Hide
          selikoff added a comment -

          Note that the issue is not limited to using milliseconds for oauth_timestamp only. If a client sends a series of requests with oauth_timestamps all in the future, the server will eventually run out of memory. For example, in our environment, having the timestamps one week in the future would have been enough to produce this issue, as the traffic was high enough that the server would crash after 5 days.

          Show
          selikoff added a comment - Note that the issue is not limited to using milliseconds for oauth_timestamp only. If a client sends a series of requests with oauth_timestamps all in the future, the server will eventually run out of memory. For example, in our environment, having the timestamps one week in the future would have been enough to produce this issue, as the traffic was high enough that the server would crash after 5 days.
          Hide
          selikoff added a comment -

          Will this be fixed in the upcoming 1.0 Jersey release, such as 1.19 or 1.20?

          Show
          selikoff added a comment - Will this be fixed in the upcoming 1.0 Jersey release, such as 1.19 or 1.20?
          Hide
          Miroslav Fuksa added a comment -

          The issue was fixed for Jersey 2.6. The fix for Jersey 1.19 is planned in the issue JERSEY-2398.

          Show
          Miroslav Fuksa added a comment - The issue was fixed for Jersey 2.6. The fix for Jersey 1.19 is planned in the issue JERSEY-2398 .

            People

            • Assignee:
              Miroslav Fuksa
              Reporter:
              selikoff
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 8 hours
                8h