<< Previous Next >>
holes
Good point, it could be an unknown kernel hole.
However it could and be a privilege escalation scenario through the
application layer .. maybe PHP, knowing its history and the fact it's
present on all the infected machines.
Anyway, nobody really knows how the initial root compromise is achieved
but it's definately one (root compromise that is).
Denis
So if we deliver proper $_POST['newimage'] and ($_POST['angle'], then
shell command injection seems to be possible ...
And as it was not bad enough - this script is callable by anyone!
No proper permissions check! So anyone in world can exploit this security
hole and run arbitrary commands against webserver's operating system!!
There are still some mitigating factors, which will decrease danger level
of this security hole.
a) ImageMagic method is not default and most Coppermine real-word
installations are using GD. So this specific security hole has impact only,
----------
Details:
----------
This hole is similar to Cross-Site Scripting vulnerability in Internet
Explorer (http://websecurity.com.ua/1241/) - CVE-2007-4478
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4478). Which I
found in August 2007 and informed Microsoft, and they ignored it and didn't
fix it in IE6, and they didn't fixed it in IE7 (and also in IE6) after my
informing in 2008. But they silently and lamerly fixed it in IE8, as I found
http://site/wp-content/plugins/gigya-socialize-for-wordpress/views/widget/widget-not-connected.php
http://site/wp-content/plugins/gigya-socialize-for-wordpress/views/widget/widget-not-logged-in.php
Users of Gigya Socialize plugin for WP must note, that developers of the
plugin didn't respond me and didn't fix the holes (like admins of one
security site, where I found these holes, which fixed only FPD holes, but
not XSS). So users of the plugin must fix it by themselves.
Best wishes & regards,
MustLive
-----------------------------
Timeline:
16.01.2009 - found XSS vulnerability.
06.04.2009 - found Command Execution vulnerability.
28.06.2009 - when I was informing developers about previous holes (which I
wrote about in previous advisory), I mentioned them that there are many
other holes in their CMS (but they ignored as previous holes, as new ones).
10.10.2009 - disclosed at my site.
11.10.2009 - additionally informed developers.
-----------------------------
> The best way to defend against any Cross Site Scripting attacks is to
> sanitize all inputs and outputs properly on your website
XSS vulnerabilities must be fixed and when they are made at web sites, then
they must be fixed at web sites. But in this case browsers developers made
XSS holes (JavaScript execution) in redirectors, so they just from
Redirector vulnerability (which can be used for redirection to malicious
sites and some other attacks) also become XSS (JavaScript execution)
vulnerability. And there are a lot of redirectors (open ones) in Internet,
as refresh-header redirectors, as location-header redirectors. So these XSS
holes better to fix in browsers, because web developers will be fixing them
All,
As a result of a short security audit of SiteBar, a number of security holes
were found. The holes included code execution, a malicious redirect and
multiple cases of Javascript injection.
After liasing with the developers, the holes have been patched. Attached are
the advisory and patch relating to these flaws.
CVEs open already relating to this audit:
"even i see no reason for this. these ip addresses arent valid
anymore. it seems that chris implemented this for a customer. i
removed it now" (they are still in the default install image)
"nvram unset ral
nvram commit "
"there is no security hole. both ip's are not active anymore and
obsolete since a long time. "
"i will lock this thread now. a new release is scheduled soon (within
this or next week), but you cannot force me to release buggy code
based on the current internal tree.thats my last statement on this
topic" (Posted: Tue Aug 19, 2008 10:57 pm)
> >guest certianly does not have permission to ptrace() pavel's
> >processes, so...
>
> But guest has permissions to ptrace() his own processes. If we
> remember your original report, he abuses input redirection of bash
> run by himself. So again, there's no real security hole here.
guest abuses ptrace permissions on his own processes to write to
pavel's files... no, that obviously is not security hole :-).
Whatever. I agree that it is obscure, but I believe that it is
This is not a hole of Kingsoft WebShield, because the CLSID value is not its.
It is Kingsoft Internet Security's web shield module.
The Kingsoft Browser Shield is currently used in Kingsoft Internet Security 2009, and that module was not used.
Therefore, that hole would not be found in Kingsoft.
On 24.10.2009 1:08, Pavel Machek wrote:
>> That can hardly be called a real security hole, since the behaviour
>> described above is expected, and is as it was conceived by design.
>> If the file owner in fact allows writing to it, why should Linux
>> prevent that from happening?
>
> No, I do not think this is expected. You could not write to that file
> under traditional unix, and you can not write into that file when
> /proc is unmounted.
>
>> itself, not to the files in it, so your pretensions are in fact
>> illegitimate.
>
> Demonstrate how to get access to the file with /proc unmounted and you
> have a point. Demonstrate how to get access on anything else then
> Linux and you have a point. Otherwise there's a security hole.
>
Did you think of creating a hardlink to the file in an unrestricted location?
That is the like "security hole".
--
On Sat 2009-10-24 01:24:49, Dan Yefimov wrote:
> On 24.10.2009 1:08, Pavel Machek wrote:
> >>That can hardly be called a real security hole, since the behaviour
> >>described above is expected, and is as it was conceived by design.
> >>If the file owner in fact allows writing to it, why should Linux
> >>prevent that from happening?
> >
> >No, I do not think this is expected. You could not write to that file
> >under traditional unix, and you can not write into that file when
> >/proc is unmounted.
> >>>guest certianly does not have permission to ptrace() pavel's
> >>>processes, so...
> >>
> >>But guest has permissions to ptrace() his own processes. If we
> >>remember your original report, he abuses input redirection of bash
> >>run by himself. So again, there's no real security hole here.
> >
> >guest abuses ptrace permissions on his own processes to write to
> >pavel's files... no, that obviously is not security hole :-).
> >
> guest abuses ptrace permissions on his own processes to write to ANY
>>>>> guest certianly does not have permission to ptrace() pavel's
>>>>> processes, so...
>>>>
>>>> But guest has permissions to ptrace() his own processes. If we
>>>> remember your original report, he abuses input redirection of bash
>>>> run by himself. So again, there's no real security hole here.
>>>
>>> guest abuses ptrace permissions on his own processes to write to
>>> pavel's files... no, that obviously is not security hole :-).
>>>
>> guest abuses ptrace permissions on his own processes to write to ANY
>>> guest certianly does not have permission to ptrace() pavel's
>>> processes, so...
>>
>> But guest has permissions to ptrace() his own processes. If we
>> remember your original report, he abuses input redirection of bash
>> run by himself. So again, there's no real security hole here.
>
> guest abuses ptrace permissions on his own processes to write to
> pavel's files... no, that obviously is not security hole :-).
>
guest abuses ptrace permissions on his own processes to write to ANY file open
violates this expectation.
It is obscure, because it requires User1 to go through an unusual sequence
of steps, but not inconceivable.
|| I don't think what Pavel described is a very serious hole, but it *IS*
|| a hole, because:
||
|| 1. It circumvents the fact that to write to a file, you MUST be able
|| to write to its directory, so that the file attributes can be updated.
|| That's an important part of accountability.
users of CB Captcha will need to wait for new release.
2. Contact Beat and ask him when developers will be releasing new version of
plugin and to hurry them.
3. Fix the hole manually. It's the most quickest solution and it's possible
that you was asking exactly about it.
To fix this vulnerability in CB Captcha you need to do, what I recommend to
developers of the plugin - to use standard algorithm of fixing such captcha
bypass method, which I called session reusing with constant captcha bypass
results about network traffic and usage trends in graphs and tables. The
software also supports SNMP (Simple Network Management Protocol). PRTG
Traffic Grapher is available at http://www.paessler.com.
In April 2009, Bkis discovered a vulnerability in PRTG Traffic Grapher.
A hacker might exploit this hole to insert malicious codes into links to
be executed in the user’ browsers, resulting in the loss of cookies,
session, etc.
Bkis has sent the warning to PRTG Traffic Grapher developer and the
vulnerability has now been fixed.
via a web browser.
Conclusions:
I stopped poking at pPIM after gleaning these details as it became
abundantly clear that the application is thoroughly riddled with holes.
pPIM fails to enforce any security in it's code, and deploying the
application produces a gaping hole in the security of any host.
Recommendations:
(from smrksoft website)
2009/10/30 Vendor contacted
2009/10/30 Vendor response (That not a security hole but a feature....)
2009/10/30 Release this advisory
#####################################################################################
============================
> "even i see no reason for this. these ip addresses arent valid
> anymore. it seems that chris implemented this for a customer. i
> removed it now" (they are still in the default install image)
> "nvram unset ral
> nvram commit "
> "there is no security hole. both ip's are not active anymore and
> obsolete since a long time. "
> "i will lock this thread now. a new release is scheduled soon (within
> this or next week), but you cannot force me to release buggy code
> based on the current internal tree.thats my last statement on this
> topic" (Posted: Tue Aug 19, 2008 10:57 pm)
Problem description:
The MyID.php script does not sanitize the input it is supposed to be given
by the site where the user wants to be authenticated. When the return_to
address does not have the same "root" as trust_root it aborts, opening a
hole for XSS attacks.
Impact:
A user can be tricked and redirected to its vulnerable identity provider,
place where the specially crafted data exploits the security hole.
/* safe_open_exist - open existing file */
***************
*** 138,150 ****
* for symlinks owned by root. NEVER, NEVER, make exceptions for symlinks
* owned by a non-root user. This would open a security hole when
* delivering mail to a world-writable mailbox directory.
*/
else if (lstat(path, &lstat_st) < 0) {
vstring_sprintf(why, "file status changed unexpectedly: %m");
errno = EPERM;
via a bot-net, etc.
Of course, simply removing the undesired iframe/script/etc tags from
your compromised pages is not enough. Although doing so does not mean
that this attacker will come back, it equally does nothing to close the
hole they used in the first place, and the next attacker searching for
that hole will hit you just as easily and indiscriminately...
Regards,
> via a bot-net, etc.
>
> Of course, simply removing the undesired iframe/script/etc tags from
> your compromised pages is not enough. Although doing so does not mean
> that this attacker will come back, it equally does nothing to close the
> hole they used in the first place, and the next attacker searching for
> that hole will hit you just as easily and indiscriminately...
>
>
> Regards,
>
This is a very serious new threat affecting Linux servers and thousands
of boxes have been compromised since December 2007.
Each box serving the nasty javascript has been rooted. One person has
found a way to CLEAN the infection (ie. stop your server from serving
the bad javascript), however not the root hole ie. the servers in
question are still rooted as nobody so far has found what hole is being
exploited to gain root access in the first place.
See the following urls for a lot more info on this exploit:
> This is a very serious new threat affecting Linux servers and thousands
> of boxes have been compromised since December 2007.
>
> Each box serving the nasty javascript has been rooted. One person has
> found a way to CLEAN the infection (ie. stop your server from serving
> the bad javascript), however not the root hole ie. the servers in
> question are still rooted as nobody so far has found what hole is being
> exploited to gain root access in the first place.
>
> See the following urls for a lot more info on this exploit:
>
---> > This is a very serious new threat affecting Linux servers and thousands
---> > of boxes have been compromised since December 2007.
---> >
---> > Each box serving the nasty javascript has been rooted. One person has
---> > found a way to CLEAN the infection (ie. stop your server from serving
---> > the bad javascript), however not the root hole ie. the servers in
---> > question are still rooted as nobody so far has found what hole is being
---> > exploited to gain root access in the first place.
--->
---> You don't need root to deface web servers in general. Even if the
---> attackers want to run bots, they often stay as the unprivileged user
> This is a very serious new threat affecting Linux servers and thousands
> of boxes have been compromised since December 2007.
>
> Each box serving the nasty javascript has been rooted. One person has
> found a way to CLEAN the infection (ie. stop your server from serving
> the bad javascript), however not the root hole ie. the servers in
> question are still rooted as nobody so far has found what hole is being
> exploited to gain root access in the first place.
You don't need root to deface web servers in general. Even if the
attackers want to run bots, they often stay as the unprivileged user
<<Previous Next>>
|
