Mailing List Archive

Re: Google vulnerabilities with PoC [ In reply to ]
I have been watching this thread for a while and I think some people are being hostile here.
 
There is nothing to gain being on eithers side but for the sake of security. As a penetration tester, writer, and malware analyst with a long and rewarding career...it would be absurd to admit that this is not a vulnerability. If the content-type fields can be altered and the API accepts it that is undoubtedly a vulnerability, I believe that it shouldn't be there. It would be a shame to say that this is not a security problem. I have seen different responses on this thread but having seen the proof of concept images as well I just think that some of the people commenting here are just being hostile.
 
It doesn't take much for somebody in the field, to see clearly that Google does not want to pay. And I bet any amount of money that the bug bounty program is a way for filing potential threats by name and bank details.
 
Rgds,
M. Kirschbaum
Re: Google vulnerabilities with PoC [ In reply to ]
I believe Zalewski has explained very well why it isn't a vulnerability,
and you couldn't possibly be calling him hostile. :)


On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:

> I have been watching this thread for a while and I think some people are
> being hostile here.
>
> There is nothing to gain being on eithers side but for the sake of
> security. As a penetration tester, writer, and malware analyst with a long
> and rewarding career...it would be absurd to admit that this is not a
> vulnerability. If the content-type fields can be altered and the API
> accepts it that is undoubtedly a vulnerability, I believe that it shouldn't
> be there. It would be a shame to say that this is not a security problem.
> I have seen different responses on this thread but having seen the proof of
> concept images as well I just think that some of the people commenting here
> are just being hostile.
>
> It doesn't take much for somebody in the field, to see clearly that Google
> does not want to pay. And I bet any amount of money that the bug bounty
> program is a way for filing potential threats by name and bank details.
>
> Rgds,
> M. Kirschbaum
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”
Re: Google vulnerabilities with PoC [ In reply to ]
On top of that, Google spent millions of dollars to buy Chrome exploits,
sandbox bypasses
and webapp bugs. So, if this was a REAL bug with some REAL security
impact, I don't think Google wouldn't have paid.

They have a REAL budget for that, they are not like Yahoo that sends you
a t-shirt.

The security industry has become a big business for many, with bug
bounties, no more free bugs (and hugs),
100 pages of low/info risk findings bumped to high risk to scare the
customer, and so on.

At least do not pretend money when there is no security bug,
and in general don't be a pretender if you don't have a clue.

Cheers
antisnatchor

Mario Vilas wrote:
> I believe Zalewski has explained very well why it isn't a vulnerability,
> and you couldn't possibly be calling him hostile. :)
>
>
> On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:
>
>> I have been watching this thread for a while and I think some people are
>> being hostile here.
>>
>> There is nothing to gain being on eithers side but for the sake of
>> security. As a penetration tester, writer, and malware analyst with a long
>> and rewarding career...it would be absurd to admit that this is not a
>> vulnerability. If the content-type fields can be altered and the API
>> accepts it that is undoubtedly a vulnerability, I believe that it shouldn't
>> be there. It would be a shame to say that this is not a security problem.
>> I have seen different responses on this thread but having seen the proof of
>> concept images as well I just think that some of the people commenting here
>> are just being hostile.
>>
>> It doesn't take much for somebody in the field, to see clearly that Google
>> does not want to pay. And I bet any amount of money that the bug bounty
>> program is a way for filing potential threats by name and bank details.
>>
>> Rgds,
>> M. Kirschbaum
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

--
Cheers
Michele
Re: Google vulnerabilities with PoC [ In reply to ]
Dear Mario,
 
There is nothing to gain being on either side. I have already read the thread replies by M. Zalewski. I believe Google is false and does not honor the security community.
 Rgds,

M. Kirschbaum
 
 
 
 
 



On Saturday, 15 March 2014, 11:11, Mario Vilas <mvilas@gmail.com> wrote:

I believe Zalewski has explained very well why it isn't a vulnerability, and you couldn't possibly be calling him hostile. :) 



On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:

I have been watching this thread for a while and I think some people are being hostile here.
> 
>There is nothing to gain being on eithers side but for the sake of security. As a penetration tester, writer, and malware analyst with a long and rewarding career...it would be absurd to admit that this is not a vulnerability. If the content-type fields can be altered and the API accepts it that is undoubtedly a vulnerability, I believe that it shouldn't be there. It would be a shame to say that this is not a security problem. I have seen different responses on this thread but having seen the proof of concept images as well I just think that some of the people commenting here are just being hostile.
> 
>It doesn't take much for somebody in the field, to see clearly that Google does not want to pay. And I bet any amount of money that the bug bounty program is a way for filing potential threats by name and bank details.
> 
>Rgds,
>M. Kirschbaum
> 
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/
>


--
“There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.”
Re: Google vulnerabilities with PoC [ In reply to ]
Some of the replies in this thread are very unfair to the original poster.



I have read the news story and have thoroughly read the proof of concepts which in my opinion indicate that this is surely a security vulnerability. I have worked for Lumension as a security consultant for more than a decade.



I have never thought that Google would have gone that far. Quite scary if you ask me... Do not be discouraged, as a security researcher I have also been getting that. I can certainly certify that this is a security problem, no doubts about that.



Big Al

_____________________________________________________________
Get your free email @
http://www.xtcmail.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
Hey,

I think the discussion digressed a little from the topic. Let's try to
steer it back on it.

What would make this a security vulnerability is one of the three standard
outcomes:

- information leak - i.e. leaking sensitive information that you normally
do not have access to
- remote code execution - in this case it would be:
-- XSS - i.e. executing attacker provided JS/etc code in another user's
browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
youtube.com)
-- server-side code execution - i.e. executing attacker provided code on
the youtube servers
- denial of service - I think we all agree this bug doesn't increase the
chance of a DoS; since you upload files that fail to be processed (so the
CPU-consuming re-encoding is never run) I would argue that this decreases
the chance of DoS if anything

Which leaves us with the aforementioned RCE.

I think we all agree that if Mr. Lemonias presents a PoC that uses the
functionality he discovered to, either:
(A) display a standard XSS alert(document.domain) in a sensitive domain
(i.e. *.youtube.com or *.google.com, etc) for a different (test) user
OR
(B) execute code to fetch the standard /etc/passwd file from the youtube
server and send it to him,
then we will be convinced that this is vulnerability and will be satisfied
by the presented proof.

I think that further discussion without this proof is not leading anywhere.


One more note - in the discussion I noticed some arguments were tried to be
justified or backed by saying "I am this this and that, and have this many
years of experience", e.g. (the first one I could find):

"have worked for Lumension as a security consultant for more than a decade."

Please note, that neither experience, nor job title, proves exploitability
of a *potential* bug. Working exploits do.


That's it from me. I'm looking forward to seeing the RCE exploits (be it
client or server side).

Kind regards,
Gynvael Coldwind
Re: Google vulnerabilities with PoC [ In reply to ]
Thank you. :)


On Sat, Mar 15, 2014 at 1:45 PM, Gynvael Coldwind <gynvael@coldwind.pl>wrote:

> Hey,
>
> I think the discussion digressed a little from the topic. Let's try to
> steer it back on it.
>
> What would make this a security vulnerability is one of the three standard
> outcomes:
>
> - information leak - i.e. leaking sensitive information that you normally
> do not have access to
> - remote code execution - in this case it would be:
> -- XSS - i.e. executing attacker provided JS/etc code in another user's
> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
> youtube.com)
> -- server-side code execution - i.e. executing attacker provided code on
> the youtube servers
> - denial of service - I think we all agree this bug doesn't increase the
> chance of a DoS; since you upload files that fail to be processed (so the
> CPU-consuming re-encoding is never run) I would argue that this decreases
> the chance of DoS if anything
>
> Which leaves us with the aforementioned RCE.
>
> I think we all agree that if Mr. Lemonias presents a PoC that uses the
> functionality he discovered to, either:
> (A) display a standard XSS alert(document.domain) in a sensitive domain
> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
> OR
> (B) execute code to fetch the standard /etc/passwd file from the youtube
> server and send it to him,
> then we will be convinced that this is vulnerability and will be satisfied
> by the presented proof.
>
> I think that further discussion without this proof is not leading anywhere.
>
>
> One more note - in the discussion I noticed some arguments were tried to
> be justified or backed by saying "I am this this and that, and have this
> many years of experience", e.g. (the first one I could find):
>
> "have worked for Lumension as a security consultant for more than a
> decade."
>
> Please note, that neither experience, nor job title, proves exploitability
> of a *potential* bug. Working exploits do.
>
>
> That's it from me. I'm looking forward to seeing the RCE exploits (be it
> client or server side).
>
> Kind regards,
> Gynvael Coldwind
>



--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”
Re: Google vulnerabilities with PoC [ In reply to ]
Gynvael Coldwind,
 
What Alfred has reiterated is that this is a security vulnerability irrelevantly of whether it qualifies for credit.
 
It is an unusual one, but still a security vulnerability. Anyone who says otherwise is blind, has little or no experience in hands on security, or either has a different agenda.
 
The obvious here is that Google dismissed it as a non-security issue which I find rather sad and somewhat ridiculous.
 
Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't be much different.
 
Rgds,
 


On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <gynvael@coldwind.pl> wrote:

Hey,

I think the discussion digressed a little from the topic. Let's try to steer it back on it. 

What would make this a security vulnerability is one of the three standard outcomes:

- information leak - i.e. leaking sensitive information that you normally do not have access to
- remote code execution - in this case it would be:
-- XSS - i.e. executing attacker provided JS/etc code in another user's browser, in the context *of a sensitive, non-sandboxed* domain (e.g. youtube.com)
-- server-side code execution - i.e. executing attacker provided code on the youtube servers
- denial of service - I think we all agree this bug doesn't increase the chance of a DoS; since you upload files that fail to be processed (so the CPU-consuming re-encoding is never run) I would argue that this decreases the chance of DoS if anything

Which leaves us with the aforementioned RCE.

I think we all agree that if Mr. Lemonias presents a PoC that uses the functionality he discovered to, either:
(A) display a standard XSS alert(document.domain) in a sensitive domain (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
OR
(B) execute code to fetch the standard /etc/passwd file from the youtube server and send it to him,
then we will be convinced that this is vulnerability and will be satisfied by the presented proof.

I think that further discussion without this proof is not leading anywhere.


One more note - in the discussion I noticed some arguments were tried to be justified or backed by saying "I am this this and that, and have this many years of experience", e.g. (the first one I could find):

"have worked for Lumension as a security consultant for more than a decade."

Please note, that neither experience, nor job title, proves exploitability of a *potential* bug. Working exploits do.


That's it from me. I'm looking forward to seeing the RCE exploits (be it client or server side).

Kind regards,
Gynvael Coldwind
Re: Google vulnerabilities with PoC [ In reply to ]
Sockpuppet much?


On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:

> Gynvael Coldwind,
>
> What Alfred has reiterated is that this is a security vulnerability
> irrelevantly of whether it qualifies for credit.
>
> It is an unusual one, but still a security vulnerability. Anyone who says
> otherwise is blind, has little or no experience in hands on security, or
> either has a different agenda.
>
> The obvious here is that Google dismissed it as a non-security issue which
> I find rather sad and somewhat ridiculous.
>
> Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't be
> much different.
>
> Rgds,
>
>
> On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <gynvael@coldwind.pl>
> wrote:
> Hey,
>
> I think the discussion digressed a little from the topic. Let's try to
> steer it back on it.
>
> What would make this a security vulnerability is one of the three standard
> outcomes:
>
> - information leak - i.e. leaking sensitive information that you normally
> do not have access to
> - remote code execution - in this case it would be:
> -- XSS - i.e. executing attacker provided JS/etc code in another user's
> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
> youtube.com)
> -- server-side code execution - i.e. executing attacker provided code on
> the youtube servers
> - denial of service - I think we all agree this bug doesn't increase the
> chance of a DoS; since you upload files that fail to be processed (so the
> CPU-consuming re-encoding is never run) I would argue that this decreases
> the chance of DoS if anything
>
> Which leaves us with the aforementioned RCE.
>
> I think we all agree that if Mr. Lemonias presents a PoC that uses the
> functionality he discovered to, either:
> (A) display a standard XSS alert(document.domain) in a sensitive domain
> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
> OR
> (B) execute code to fetch the standard /etc/passwd file from the youtube
> server and send it to him,
> then we will be convinced that this is vulnerability and will be satisfied
> by the presented proof.
>
> I think that further discussion without this proof is not leading anywhere.
>
>
> One more note - in the discussion I noticed some arguments were tried to
> be justified or backed by saying "I am this this and that, and have this
> many years of experience", e.g. (the first one I could find):
>
> "have worked for Lumension as a security consultant for more than a
> decade."
>
> Please note, that neither experience, nor job title, proves exploitability
> of a *potential* bug. Working exploits do.
>
>
> That's it from me. I'm looking forward to seeing the RCE exploits (be it
> client or server side).
>
> Kind regards,
> Gynvael Coldwind
>
>
>


--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”
Re: Google vulnerabilities with PoC [ In reply to ]
Hello... I am an IT security expert for the Emirates National Oil Company. Google is my favourite search engine by far. Now I just read the report about the unrestricted upload issue and I think that the author is right that it is a security problem. This is a vulnerability because file name extension verification's not been used properly. The problem here has also been with the returned MIME type returned from the API $_FILES['uploadedfile']['type']” holds the value of the MIME type. Tampering the HTTP Post request can exploit the functionality. An attacker can bypass this protection by changing the MIME type of the shell.php to “image/gif”. So when an application checks the MIME type, it seems like a gif file. The application will then upload the malicious code shell.php. That is something that definitely needs to be fixed, if it hasn't already. Definetely a security problem. http://resources.infosecinstitute.com/file-upload-vulnerabilities/"]http://resources.infosecinstitute.com/file-upload-vulnerabilities/


Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com
Re: Google vulnerabilities with PoC [ In reply to ]
Is it possible with the help of Godwin's law
this discussion moves offlist?

--
guninski

On Thu, Mar 13, 2014 at 10:43:50AM +0000, Nicholas Lemonias. wrote:
> Google vulnerabilities uncovered...
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
How the hell did you ever think Google will honor this? By now they
could be fixing this issue, they hell don't care about you.



On 3/15/14, Georgi Guninski <guninski@guninski.com> wrote:
> Is it possible with the help of Godwin's law
> this discussion moves offlist?
>
> --
> guninski
>
> On Thu, Mar 13, 2014 at 10:43:50AM +0000, Nicholas Lemonias. wrote:
>> Google vulnerabilities uncovered...
>>
>>
>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


--
--
Gichuki John Ndirangu, C.E.H , C.P.T.P, O.S.C.P
I.T Security Analyst and Penetration Tester
jgichuki at inbox d0t com

{FORUM}http://lists.my.co.ke/pipermail/security/
http://chuksjonia.blogspot.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

1 2 3  View All