commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IO-71) [io] PipedUtils
Date Wed, 13 Feb 2008 14:33:08 GMT

    [ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568559#action_12568559
] 

David Smiley commented on IO-71:
--------------------------------

I agree with what you're saying.  But as far as it being "not too much of an issue"... I wonder
if the risk isn't so much "normal expected data" but  instead a security concern resulting
in a denial of service.  Lets say hypothetically that we had some decompressing outputstream.
 So if the input size is X, then the output would generally be larger than X (and hence the
requirements of our buffer).  In normal data the ratio might be a ratio of say 1:10 and since
your code requests data in 1KB chunks, it'd need a 10KB buffer.  But an attacker might give
this system data that has an extreme compression ratio of say 1:100000000000 (lots of zeroes,
whatever).  Like say a 100MB file consisting of all one's which would compress like mad. 
A system based on this code would then consume all available memory and more or less crash.
 The size of the input file needed to cause this to occur depends on both the deployed environment
and the compression ratio achievable.

I admit I'm sort of a perfectionist so I may be making a bigger deal out of this than is warranted.

If you really do insist on a variation of your solution, I recommend you have internal warning
thresholds which cause warnings to be logged beyond certain thresholds to alert people of
a potential problem.

> [io] PipedUtils
> ---------------
>
>                 Key: IO-71
>                 URL: https://issues.apache.org/jira/browse/IO-71
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>         Environment: Operating System: All
> Platform: All
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 2.x
>
>         Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch
>
>
> I developed some nifty code that takes an OutputStream and sort  of  reverses it as if
it were an 
> InputStream.  Error passing and  handling  close is dealt with.  It needs another thread
to do the  work 
> which  runs in parallel.  It uses Piped streams.  I created  this because I  had to conform

> GZIPOutputStream to my framework  which demanded an  InputStream.
> See URL to source.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message