FW: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe Macromedia Flash Products Multiple Vulnerabilities
by David Eisenstein
Hi folks,
"There are critical vulnerabilities in Macromedia Flash player and
related software. Exploitation of these vulnerabilities could allow a
remote, unauthenticated attacker to execute arbitrary code or cause a
denial of service on a vulnerable system."
For more detailed info, please see the forwarded message from CERT,
below.
Although I don't believe that Fedora or Fedora Legacy provides any version
of Macromedia's Flash Player to our end users (as it's proprietary), end
users may still decide to download and install this free plugin ... so it
is good to know about this. I believe Flash is able to be used both with
Firefox and Mozilla. Perhaps KDE's Konqueror also can use Flash.
Someone who knows for sure about Konqueror, can you respond on the list
and let us know?
One workaround one can do to not be vulnerable is to disable Flash, at
least until a secure version can be installed. I use Mozilla-1.7.12.
What I do to disable flash (and I rarely have it enabled ;)) is:
1) Shut down your browser and (Mozilla-based) email program, if open.
2) Do a '$ find /usr/lib -iname 'libflash*.so'.
3) It may find the flash player (possibly named 'libflashplayer.so')
under any of these directories:
/usr/lib/mozilla/plugins/
/usr/lib/mozilla-(version)/plugins
/usr/lib/firefox-(version)/plugins
4) Wherever it finds the plugin .so (shared-object) file, then (as
root) either delete the file, or rename it to something your
browser will not find to load. I rename it to
'no_libflashplayer.so.txt'.
5) At this point, the flash player should be disabled, so when you
next start Mozilla and/or Firefox you should be safe from this
vulnerability.
I make no warrantee that the above suggestions for disabling the flash
player will work for you. You take the above steps AT YOUR OWN RISK!
If anyone has a better way to suggest disabling the Macromedia Flash
player, will you please respond to this message with your suggestion(s)?
Thanks.
For those of you already aware of this, my apologies for the duplication.
Regards,
David Eisenstein
---------- Forwarded message ----------
From: US-CERT Technical Alerts <technical-alerts(a)us-cert.gov>
To: technical-alerts(a)us-cert.gov
Date: Thu, 16 Mar 2006 18:13:56 -0500
Subject: US-CERT Technical Cyber Security Alert TA06-075A -- Adobe
Macromedia Flash Products Multiple Vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
National Cyber Alert System
Technical Cyber Security Alert TA06-075A
Adobe Macromedia Flash Products Contain Vulnerabilities
Original release date: March 16, 2006
Last revised: --
Source: US-CERT
Systems Affected
Microsoft Windows, Apple Mac OS X, Linux, Solaris, or other operating
systems with any of the following Adobe Macromedia products installed:
* Flash Player 8.0.22.0 and earlier
* Flash Professional 8
* Flash Basic
* Flash MX 2004
* Flash Debug Player 7.0.14.0 and earlier
* Flex 1.5
* Breeze Meeting Add-In 5.1 and earlier
* Adobe Macromedia Shockwave Player 10.1.0.11 and earlier
For more complete information, refer to Adobe Security Bulletin
APSB06-03.
Overview
There are critical vulnerabilities in Macromedia Flash player and
related software. Exploitation of these vulnerabilities could allow a
remote, unauthenticated attacker to execute arbitrary code or cause a
denial of service on a vulnerable system.
I. Description
Adobe Security Bulletin APSB06-03 addresses vulnerabilities in
Macromedia Flash Player and related software. Further information is
available in the following US-CERT Vulnerability Note:
VU#945060 - Adobe Macromedia Flash products contain multiple
vulnerabilities
Several vulnerabilities in Adobe Macromedia Flash products may allow a
remote attacker to execute arbitrary code on a vulnerable system.
(CVE-2006-0024)
Several operating systems, including Microsoft Windows (see Microsoft
Security Advisory 916208), have vulnerable versions of Flash installed
by default. Systems with Flash-enabled web browsers are vulnerable. An
attacker could host a specially crafted Flash file on a web site and
convince a user to visit the site.
II. Impact
A remote, unauthenticated attacker could execute arbitrary code with
the privileges of the user. If the user is logged on with
administrative privileges, the attacker could take complete control of
an affected system. An attacker may also be able to cause a denial of
service.
III. Solution
Apply Updates
Adobe has provided the updates for these vulnerabilities in APBS06-03.
Disable Flash
Please see Microsoft Security Advisory 916208 for instructions on how
to disable Flash on Microsoft Windows. For other operating systems and
web browsers, please contact the appropriate vendor.
Appendix A. References
* Macromedia - APSB06-03: Flash Player Update to Address Security
Vulnerabilities -
<http://www.macromedia.com/devnet/security/security_zone/apsb06-03
.html>
* US-CERT Vulnerability Note VU#945060 -
<http://www.kb.cert.org/vuls/id/945060>
* CVE-2006-0024 -
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0024>
* Microsoft Security Advisory (916208) -
<http://www.microsoft.com/technet/security/advisory/916208.mspx>
____________________________________________________________________
The most recent version of this document can be found at:
<http://www.us-cert.gov/cas/techalerts/TA06-075A.html>
____________________________________________________________________
Feedback can be directed to US-CERT Technical Staff. Please send
email to <cert(a)cert.org> with "TA06-075A Feedback VU#945060" in the
subject.
____________________________________________________________________
For instructions on subscribing to or unsubscribing from this
mailing list, visit <http://www.us-cert.gov/cas/signup.html>.
____________________________________________________________________
Produced 2006 by US-CERT, a government organization.
Terms of use:
<http://www.us-cert.gov/legal.html>
____________________________________________________________________
Revision History
Mar 16, 2006: Initial release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iQEVAwUBRBnrc30pj593lg50AQJh0Af/WnwWF6RIXfF6zpDCXMzkEjdaiWUSDa+g
utKrN8ZwUqKsPVw/uKR9vLwqWrWRYbTAsVjnFd1TBiBcasxAPIM4Y0u8sYCnXldB
NmpotYhMPiuIIh7t/2bGxaAwOB8yBZvN4GNGDarsiK243/nf0m8Y7e6t+XN5FY6V
nDp+q8mxiPN0T7Bh+ofeEX7m7SOEAza7kBwzsGgRSZzIkVmwH1+pBjPznmM1Zylh
UzpTPhmvKkQtuDJ3iG3P0J6hrNZqTukEcOh5VB9gRhfvzpavSa6sXoiI7+/zTADa
IJ8ZZZ6crFYmP/DTPeA9nbeCtQg/HAu+ty6ME/leVsHah3a16NWm4w==
=XJw+
-----END PGP SIGNATURE-----
17 years, 6 months
Summary of FC5 vulnerabilities
by Mark Cox
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quick Summary:
For 20030101-20060320 there are a potential 1361 CVE named vulnerabilities
that could have affected FC5 packages. 90% of those are fixed because FC5
includes an upstream version that includes a fix, 1% are still
outstanding, and 9% are fixed with a backported patch. Many of the
outstanding and backported entries are for issues still not dealt with
upstream.
For comparison FC4 had 88% by version, 1% outstanding, 11% backported.
Method:
Near the release time of each new distribution the Red Hat security
team go through the packages to ensure that everything is up to date
with security patches. Full details of the method can be found
http://people.redhat.com/mjc/20050505-fc4
A full table of CVE name, the reason why FC5 isn't vulnerable and optional
comments showing the package name, version it was fixed in, or method used
to verify the details is available:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/fc5?root=fedora
This file will be kept up to date through the life of FC5 to track
publically known vulnerabilities and how they affect FC5.
Corrections, comments to secalert(a)redhat.com.
Thanks, Mark
- --
Mark J Cox / Red Hat Security Response Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iQCVAwUBRB57f+6tTP1JpWPZAQIRAgQApmCQEUeH4vbMBJABLsFPXmyvkhlbfN+X
mRMcFOHjIc/bekCGb864f64rDxbs+piLE7uXZak4zio7xAKRdWT5z28X2TgprcS8
VT+XBIzix0+vGni8JzDKpEZEq6FTE6zPG22gDfxGAwt9K0qxHGxb1JkY/Syh7wjI
V7vi8XFlaag=
=dnuD
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
17 years, 6 months
Re: Possibility to send FE security announcements to the FC announcement list?
by Bill Nottingham
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
> I'm one of the people who is trying to get FE security organised, see:
> https://www.redhat.com/archives/fedora-security-list/2006-March/msg00011....
>
> One of the questions we are trying to answer is where to send FE
> security announcements. We would like to send these to the list (and in
> the same format) where FC security announcements get send. Josh Bressers
> told me you own that list and that I should ask you, so here we are.
I don't have a conceptual problem with it. You'd probably want to also
start using Luke's code for XML advisory info in the repodata, since we're
going to roll that out for Core at some point in the future.
Bill
17 years, 6 months
fedora-security/audit
by Hans de Goede
Hi,
I just saw commit messages on the cvs-list for fedora-security/audit.
Whats is this file (I know the answer seems obvious). What is its
purpose how up to date is it. Is someone putting the found
vulnerabilities in bugzilla?
I think that this file is _great_, yet notting seems to be done with it?
Regards,
Hans
17 years, 6 months
Getting FE security (team/sig) moving / on the road
by Hans de Goede
Hi all,
I just subsribed to this list, but I know from the archive that this has
already been somewhat discussed on the list, still for completness first
a short intro.
For people outside the loop:
We a small group of FE contributers have been discussing creating /
instantitiating a FE security sig / team.
What we have sofar can be found on:
http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy
The last 2 weeks it has been rather quiet in our little group I would
like to get the discussion on FE-security kickstarted again, hence this
mail.
To the people in the CC, afaik you're not subscribed yet, but you were
involved in the FE security discussion sofar. We initially commited to
taking this discussion public monday a week ago, well clearly we didn't.
So I'm taking it public through this list now and I would like todo the
rest if this discussion on this list, please subscribe.
To the people on the list please use reply to all so that those in the
CC stay involved in this thread.
After this intro hopefully everybody knows what I'm talking about / is
up2date, so now lets look forward.
My proposal to get an Fedora Extra Security Team on the road is as follows:
Fesco will discuss:
http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy
Coming Thursday, hopefully with some improvements but if nescesarry as
is. I know that gives us just a few days to discuss any improvements,
but things have already been widely discussed and after that we've all
been quiet for a while. So I think its about time to take this to the
next level.
All in favor of getting this on the FESco speaking schedule soon say I
:) I ofcourse vote for my own proposal.
So we need to get:
http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy
in tip-top shape before thursday. So what suggestions have come up sofar:
---
Josh bressers wrote:
"I've looked that document over in the past. I admit the times at the end
chart scare me. That's a fairly complicated chart. Within Red Hat there
was discussion about how to best classify security issues, this is what we
came up with:
http://www.redhat.com/security/updates/classification/
When one has to classify security threats, less is more.
I would suggest something more along these lines:
Critical: Don't bother waiting for the maintainer, do whatever it takes to
fix it.
Important: A few days.
Moderate: A few weeks.
Low: A few months."
I agree that its a good idea to use the RedHat security team
classifications. Anyone feel like updating the wiki (I'm low on time)?
About the suggested response time I join sides with Jason that their
should be a response time for Critical bugs, not automatic take-over by
the FE security team.
Also I think the times should be shorter then suggested by Josh, we're
talking about ping times here, not time till fix. Maybe we need another
word here. The biggest problem sofar is people who have been dead quiet
in bugzilla. So if I say the security team takes over if their is no
response within a week, I mean no response _at all_ if the maintainer
says yip that looks like a problem I'll look into it, then he has
responded and the response timer gets reset. so in this case as long as
a maintainer makes an entry about his progress every week all is ok and
the FE security team does not step in. The team could ofcourse offer
help suggest fixes, but we won't step in and push a fix, that is left to
the maintainer.
---
In general one of things which needs updating in our proposal the most
is that it should be made very clear that the FE security team is a
fallback and a fallback only. Normally the maintainers are 100%
responsible for the security updates for their own packages (for as far
as a volunteer can be responsible, the should feel 100% responsible.)
Can a native English speaker put something like this in their in very
strong yet friendly words?
---
Besides the response time and the making very clear that security is the
maintainers responsibility not the security teams we still need to work
out the Open issues list. As I've suggested before:
-I would like to suggest to send announcement to the list (and in the
same format) where FC security announcements get send, Josh is this
possible, can we get direct access, or maybe through you/ the whole
RH-security team?
-The FE security team needs a way to get involved in bugs / fixes where
all the info is under embargo. Again Josh, can you/ the whole
RH-security team play a role here? We ofcourse only need to be in the
loop if a package within FE has a hole.
-I've used the word FE security team instead of SIG above because I
think to the outside team sounds a lot better (professional) then SIG,
and this well help in being taking serious by the outside world (for
embargos for example) this has 2 disadvantages however:
*maintainers could get the idea that the team is responsible for the
security fixes, which its not they (the maintainers) are
*confusion with the redhat security team
So I'm not sure which name is better team or sig.
Thanks for your time reading this and please give your much valued opinion.
Regards,
Hans
17 years, 6 months
Secunia pages -- publishing wrong and misleading information about security status of Fedora distros?? RE: [Fedora Project Wiki] Update of "Security" by JoshBressers (fwd)
by David Eisenstein
Hi,
Was noticing one of Josh Bresser's edits to wiki/Security today... (see
the forward below).
If Secunia's information is incorrect and misleading, misrepresenting the
true security status of Fedora distributions, oughtn't we get in touch
with Secunia to help coordinate updating their information to make it
correct and informative?
They claim to welcome feedback:
"If you have new information regarding a Secunia advisory or a
product in our database, please send it to us using either our web
form or email us at vuln(a)secunia.com.
"Ideas, suggestions, and other feedback is most welcome."
It seems that Secunia may be doing us a service, putting a lot of work
into informing the public of details about the security status of various
Linux distros including Fedora -- work we may not have time to do and so
are not doing at the moment. Perhaps we can support their work rather
than just putting our heads in the sand and pretending it's not there
misrepresenting the security status?
(a little later)
Okay, now I've actually *looked* at Secunia's pages... Hrm. It looks
like Secunia only talks about issues that have releases published, and
then only from the fedora-announce-list. They have nothing in their pages
about vulnerabilities fixed by Fedora Legacy. (For example, see
<http://secunia.com/graph/?type=adv&period=all&prod=2568> for FC1, which
Fedora Legacy continues to maintain.)
And, since it appears they're only reporting from announcements of fixed
packages, of course their little pie charts would show 100% fixed. (For
example, see <http://secunia.com/graph/?type=sol&period=all&prod=5251> for
Fedora Core 4.) It looks like they're doing no original research at all
(like looking at CVE's from cve.mitre.org) to see if distros have any
unpatched vulnerabilities ...
Does Secunia have folks that can be worked with so their Fedora pages can
become reliable enough so we *can* have them linked to as a third-party
site in our wiki?? And further, do any of us who work with security
issues have *time* to invest in working with them to bring them in line
with reality, assuming they're open to suggestions?
Regards,
David Eisenstein
---------- Forwarded message ----------
From: fedorawiki-noreply(a)fedoraproject.org
To: fedorawiki-noreply(a)fedoraproject.org
Date: Fri, 03 Mar 2006 22:32:50 -0000
Subject: [Fedora Project Wiki] Update of "Security" by JoshBressers
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Fedora Project Wiki" for change notification.
The following page has been changed by JoshBressers:
http://fedoraproject.org/wiki/Security
The comment on the change is:
The secunia pages are very wrong and misleading.
------------------------------------------------------------------------------
@@ -38, +38 @@
* http://fedoraproject.org/wiki/Presentations
- == Third-Party Information ==
-
- Secunia:
- * [http://secunia.com/product/5251/ Secunia's Vulnerability Report for Fedora Core 4]
- * [http://secunia.com/product/4222/ Secunia's Vulnerability Report for Fedora Core 3]
- * [http://secunia.com/product/3489/ Secunia's Vulnerability Report for Fedora Core 2]
- * [http://secunia.com/product/2568/ Secunia's Vulnerability Report for Fedora Core 1]
- * [http://secunia.com/vendor/3/ Secunia's Red Hat vendor page]
-
----
CategoryDocumentation CategorySecurity
17 years, 6 months
Hi and wiki
by David Eisenstein
Just coming in to say hi. Also wanted to mention that I placed an
initial reference to this new list here:
<http://fedoraproject.org/wiki/Security>
Josh, or anyone, if you feel you can put it better, please, be my guest
and change it to better reflect reality. :-)
Warm regards,
David Eisenstein
17 years, 6 months
