You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Jake Cobb (JIRA)" <ji...@apache.org> on 2010/03/25 16:33:27 UTC

[jira] Created: (CODEC-98) Base64InputStream causes NullPointerException on some malformed input

Base64InputStream causes NullPointerException on some malformed input
---------------------------------------------------------------------

                 Key: CODEC-98
                 URL: https://issues.apache.org/jira/browse/CODEC-98
             Project: Commons Codec
          Issue Type: Bug
    Affects Versions: 1.4
         Environment: N/A
            Reporter: Jake Cobb
            Priority: Critical


Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.

The exception occurs when {{Base64.decode}} is entered with the following conditions:

* {{buffer}} is {{null}}
* {{modulus}} is {{3}} from a previous entry.
* {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.

Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.

Here is some input data that will trigger it:

{noformat}
H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
/xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
{noformat}

Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.

{{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.


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


[jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849800#action_12849800 ] 

Gary Gregory commented on CODEC-98:
-----------------------------------

So what should the behavior be on bad input? Garbage in, garbage out, no NPE? It's not complete garbage out in the case you describe where the end of the transmission is lopped off and causes an NPE.

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Closed: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies closed CODEC-98.
------------------------------

    Fix Version/s: Nightly Builds
       Resolution: Fixed

Committed to trunk: http://svn.apache.org/viewvc?view=revision&revision=950267

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>             Fix For: Nightly Builds
>
>         Attachments: codec-98-fix.patch, codec-98-tests.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849773#action_12849773 ] 

Gary Gregory commented on CODEC-98:
-----------------------------------

Thank you for the report. Can you please provide a unit test that demonstrate the issue?

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Updated: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated CODEC-98:
-------------------------------

    Attachment: codec-98-fix.patch

Sorry, accidentially clicked " Attachment not intended for inclusion" radio last time.

Just to be clear, this 3 line patch _IS_ granted to ASF for inclusion in ASF works.





> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-fix.patch, codec-98-tests.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Updated: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Jake Cobb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jake Cobb updated CODEC-98:
---------------------------

    Summary: Base64InputStream causes NullPointerException on some input  (was: Base64InputStream causes NullPointerException on some malformed input)

Removed 'malformed' from summary since I'm not sure this is actually the case.

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Updated: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated CODEC-98:
-------------------------------

    Attachment:     (was: codec-98-fix.patch)

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-tests.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Jake Cobb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849837#action_12849837 ] 

Jake Cobb commented on CODEC-98:
--------------------------------

>From {{Base64InputStream}}, {{IOException}} or a more specific subclass thereof would be appropriate.  Client code handling the stream will have to be expecting a possible {{IOException}}, but a NPE when {{read}}'s argument is known to be non-{{null}} is not expected and unlikely to be caught in a helpful place (if it gets caught at all).

For {{Base64}}, {{DecoderException}} could be thrown by {{Base64.decode}}.  Although this is adding a checked exception, the method is package-private so you should have some flexibility.  It looks like the public methods already throw this.  {{Base64InputStream}} could then wrap the {{DecoderException}} in an {{IOException}}.

If someone had a use-case for wanting the portion that was decoded successfully despite knowing an error occurred, you could modify the exception to allow partial results to be attached.  Personally, I don't consider this necessary but others may disagree.

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Updated: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated CODEC-98:
-------------------------------

    Attachment: codec-98-tests.patch


Here are some JUnits to trigger the NPE.  I managed to trigger it with Base64OutputStream as well.



> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-fix.patch, codec-98-tests.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Issue Comment Edited: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850382#action_12850382 ] 

Julius Davies edited comment on CODEC-98 at 3/26/10 10:28 PM:
--------------------------------------------------------------

The attached patch file fixes it!  I'll upload unit tests within next 2 hours.

I'm using my own test case:
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM

Notice that Base64.decodeBase64() is able to deal with it:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123

But Base64InputStream is not (with buffer of size 1024).  So this isn't an example of garbage-in/garbage-out.  This is valid input blowing up inside Base64InputStream!


      was (Author: juliusdavies):
    This fixes it!  I'll upload unit tests within next 2 hours.

I'm using my own test case:
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM

Notice that Base64.decodeBase64() is able to deal with it:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123

But Base64InputStream is not (with buffer of size 1024).  So this isn't an example of garbage-in/garbage-out.  This is valid input blowing up inside Base64InputStream!

  
> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-fix.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Jake Cobb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849794#action_12849794 ] 

Jake Cobb commented on CODEC-98:
--------------------------------

Here's one with a shorter input.  Basically, you can encode something to Base64 and then knock a character or two off the end of a line and it will usually be a triggering input.  However, if you use the input below with everything from "//" to the end removed, it doesn't trigger the NPE.

\\
{code:title=Base64NPETest.java}
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.UnsupportedEncodingException;

import org.apache.commons.codec.binary.Base64InputStream;
import org.junit.Test;

public class Base64NPETest
{
	public static final String INPUT =
		"H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJi";

	@Test
	public void testCodec98() throws UnsupportedEncodingException
	{
		ByteArrayInputStream data = new ByteArrayInputStream(INPUT.getBytes("UTF-8"));
		try
		{
			Base64InputStream stream = new Base64InputStream(data);
			byte[] buf = new byte[1024];
			int read = 0;
			while( read != -1 )
				read = stream.read(buf);
			// success if no NPE by this point
		}
		catch(IOException ignore) 
		{ 
			System.err.println("Ignoring IOException");
		}
	}
}
{code}

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850411#action_12850411 ] 

Gary Gregory commented on CODEC-98:
-----------------------------------

Julius: 

Your patch https://issues.apache.org/jira/secure/attachment/12439927/codec-98-fix.patch is not licensed for Apache, there is no Apache feather next to the patch link in this ticket.

Can remove and resubmit? Thank you.

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-fix.patch, codec-98-tests.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


[jira] Updated: (CODEC-98) Base64InputStream causes NullPointerException on some input

Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julius Davies updated CODEC-98:
-------------------------------

    Attachment: codec-98-fix.patch

This fixes it!  I'll upload unit tests within next 2 hours.

I'm using my own test case:
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM

Notice that Base64.decodeBase64() is able to deal with it:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123

But Base64InputStream is not (with buffer of size 1024).  So this isn't an example of garbage-in/garbage-out.  This is valid input blowing up inside Base64InputStream!


> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>         Attachments: codec-98-fix.patch
>
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}} in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}} and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.  In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}} and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters {{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}}, {{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I think the real fix needs to happen in {{Base64}} since it this same situation could be created by direct use.  My guess is either more needs to happen in the body of the {{if}} on line {{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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