tag:blogger.com,1999:blog-25180995366903305732024-03-08T00:42:10.548-06:00OSG Security News and AnnouncementsAnonymoushttp://www.blogger.com/profile/14816441477644992002noreply@blogger.comBlogger28125tag:blogger.com,1999:blog-2518099536690330573.post-72693759875863369552015-01-22T11:38:00.000-06:002015-01-22T11:38:39.490-06:00Oracle releases security updates for Java this weekOracle has released new versions of Java to address multiple security issues. There does not appear to be any remote unauthenticated vulnerabilities in server installs, however there are serious vulnerabilities in client side installs.<br />
<div>
<br /></div>
<div>
As a precaution, everyone is recommended to install the latest Java patches. Scientific Linux and Red hat have both released updated Java packages. New packages for Mac and Windows systems are also available.<br />
<br />
<a href="http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html#AppendixJAVA">A listing of vulnerabilities addressed is available here</a>.</div>
KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-61446235821694026682014-12-17T15:32:00.000-06:002014-12-17T15:32:14.625-06:00News for OSG users with CILogon CA certificates<div class="p1">
The OSG Security Team wants to inform that Protect Network, one of the</div>
<div class="p1">
Identity Providers accepted by the CILogon CA, will no longer be</div>
<div class="p1">
available after 12/31/2014. Most OSG users are getting certificate</div>
<div class="p1">
directly via the OSG CA, however CILogon has been available as an option</div>
<div class="p1">
for a number of years.</div>
<div class="p2">
<br /></div>
<div class="p1">
If you have been getting personal certificates via cilogon.org, and have</div>
<div class="p1">
been using Protect Network to authenticate, you will no longer be able</div>
<div class="p1">
to get new certificates after 12/31/2014.</div>
<div class="p2">
<br /></div>
<div class="p1">
We recommend using your home institution's Identity Provider if it is</div>
<div class="p1">
available on the pulldown list on the cilogon.org website, get a new</div>
<div class="p1">
certificate via the OSG CA, or else renew your current cert before the</div>
<div class="p1">
end of the year and then seek other arrangements.</div>
<div class="p2">
<br /></div>
<div class="p1">
If you need help getting a certificate to replace a cilogon.org/Protect</div>
<div class="p1">
Network certificate, please contact the security team by opening a GOC</div>
<div class="p1">
ticket.</div>
<div class="p2">
<br /></div>
<div class="p1">
Some useful links:</div>
<br />
<div class="p1">
* http://cilogon.org/osg</div>
<div class="p1">
<br /></div>
<div class="p1">
Kevin Hill</div>
<div class="p1">
</div>
<div class="p1">
on behalf of the OSG Security Team</div>
KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-64322965389587191142014-06-25T16:00:00.002-05:002014-06-25T16:00:35.070-05:00Warning about IPMIThe Intelligent Platform Management Interface (IPMI) is a remote management system included in many server systems. Several recent vulnerabilities in IPMI systems have been found to be remotely exploitable. It is highly recommended that any systems with IPMI be configured to not allowed access from the general internet, either by configuring a private network, or blocking access with a firewall. US-CERT recently published an alert on this as well:<br />
<a href="http://www.us-cert.gov/ncas/alerts/TA13-207A">http://www.us-cert.gov/ncas/alerts/TA13-207A</a><br />
<br />KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-21502982165872193522013-06-11T08:48:00.001-05:002013-06-11T08:48:31.350-05:00Introduction to the CILogon Basic CACILogon Basic CA is a service that allows students at Universities with existing single sign-on systems to use their campus credentials to get a certificate issued by the CILogon Basic CA instantly. This certificate is only issued if the campus single sign-on system verifies the users credentials.<br />
<br />
If you manage an OSG VO and your University is already on the list of sites on the CILogon Basic CA web page, <a class="moz-txt-link-freetext" href="http://cilogon.org/osg">http://cilogon.org/osg</a>, then you can have your VO members get CILogon Basic CA certificates now. Note that in addition to getting a certificate, it will also have to be registered with your VO's VOMS service. This provides an additional security check on all certificate registrations.<br />
<br />
If you run an OSG site, the OSG Security Team is looking for sites willing to accept CILogon Basic CA certificates from users for access to your resources. In most cases this involves just installing the cilogon-ca-certs rpm.<br />
<br />
The downside to the CILogon Basic CA for some people is that there is one provider, protect.net, which will let anyone with a valid email address request an account.<br />
<br />
This is not a problem for grid services, since in addition to a valid certificate, a grid user will need a DN mapping entry in their VO's VOMS server or gridmap files before they can access any grid resources. If, however, other services such as web pages are restricted to any valid client certificate, then those permissions might want to be revisited with CILogon Basic CA certificates installed, as they will more than likely include more than just research related individuals.<br />
<pre wrap="">
</pre>
KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-40716573652532981772013-03-08T14:19:00.000-06:002013-03-08T14:19:05.733-06:00Java security updates released this weekOracle has released a new version of Java 6 and Java 7 in response to new vulnerabilities that allow malicious web sites to allow full access to systems when web browsers with Java enabled visit them.<div>
<br /></div>
<div>
This only affects client side use of Java, as in web start apps or the Java plugin in web browsers. It should not be exploitable by server side uses of Java. </div>
<div>
<br /></div>
<div>
As a precaution, however everyone is recommended to install the latest Java patches. Scientific Linux and Red hat have both released updated Java 6 and 7 packages. New packages for Mac and Windows systems are also available. </div>
<div>
<br /></div>
KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-11369461941305266022013-01-15T09:07:00.000-06:002013-01-15T09:07:26.068-06:00New Java Exploit in the Wild<br />
Last week a vulnerability was discovered in Java 7 that allowed compromised web sites to take control of computers visiting the site with a web browser with the Java plugin enabled. This has been reported to be actively exploiting systems in the wild.<br />
<br />
The vulnerability seems to be specific to Java 7, and specifically the web browser plugin, so grid services do not seem to be vulnerable.<br />
<br />
Oracle has released a new version of Java as of Sunday that should fix this vulnerability. It is recommended that people disable the Java browser plugin if its not needed until the update is installed.<br />
<br />
Here's an article that has a good list of FAQs about this vulnerability:<br />
https://krebsonsecurity.com/2013/01/what-you-need-to-know-about-the-java-exploit/KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-30109055869255454822012-07-31T14:53:00.000-05:002012-07-31T15:00:22.585-05:00Ganglia VulnerabilityThere is a <a href="http://ganglia.info/?p=549">Ganglia vulnerability</a> that potentially allows remote users to execute unauthorized scripts. This <a href="http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/ganglia-web.html">has been fixed</a> in the EPEL Ganglia for EL6, and <a href="https://bugzilla.redhat.com/show_bug.cgi?id=840318">doesn't seem to affect</a> the EPEL Ganglia for EL5.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-78983995155515062842012-07-17T10:57:00.002-05:002012-07-17T10:57:43.817-05:00sudo updateAn <a href="http://listserv.fnal.gov/scripts/wa.exe?A2=ind1207&L=scientific-linux-errata&T=0&P=4508">update for sudo</a> was released yesterday which can prevent privilege escalation in certain situations.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-887205039112452612012-07-10T13:06:00.000-05:002012-07-10T13:06:31.804-05:00Scientific Linux UpdatesSince Thursday there have been 31 Scientific Linux updates announced, mostly for SL6. <a href="http://listserv.fnal.gov/scripts/wa.exe?A1=ind1207&L=scientific-linux-errata&O=D&H=0&D=0&T=0">The full list is here.</a> Also, a local user privilege escalation bug fix for the SL6 kernel <a href="http://listserv.fnal.gov/scripts/wa.exe?A2=ind1206&L=scientific-linux-errata&T=0&O=D&P=2223">was announced</a> a few weeks ago. Please upgrade as needed. <br />
<br />Unknownnoreply@blogger.comtag:blogger.com,1999:blog-2518099536690330573.post-48319653835416144782012-04-20T15:38:00.000-05:002012-04-20T15:38:05.071-05:00Kernel and GridEngine updates this week<h2>
Kernel update for Red Hat and Scientific Linux</h2>
Red Hat and Scientific Linux have both released updated kernel packages to address a local denial of service vulnerability in the xfrm6_tunnel kernel module.<br />
<a href="https://rhn.redhat.com/errata/RHSA-2012-0480.html">The redhat announcement is here.</a><br />
<br />
<h2>
Updates to Oracle Grid Engine</h2>
Oracle has released updates to Oracle Grid Engine to address two local privilege escalation vulnerabilities, one in the qrsh component and the other in sgepasswd.<br />
<a href="http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html#AppendixSUNS">Oracle advisory is here.</a>KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-81047236687275165002012-04-06T18:26:00.000-05:002012-04-06T18:26:19.278-05:00A Couple Noteworthy Security Updates<h3>
Apple Update for Java</h3>
Apple has released an update for Java for Lion and Snow Leopard to
address critical vulnerabilities that can lead to the compromise of
systems using Java, especially in web browsers. Systems are being actively
exploited
in the wild. At this time, we have not yet received reports of
infected Macs from OSG users, however reports estimate over 600,000
Macs have been compromised so far: <a href="http://www.pcworld.com/businesscenter/article/253268/fastgrowing_flashback_botnet_includes_over_600000_macs_malware_experts_say.html">[PC World Article]</a><br />
<br />
Apple's original announcement is here: <a href="http://support.apple.com/kb/HT5228">[Apple Announcement]<br />
</a><br />
A good quick guide to checking if your Mac is infected is available
here:
<a href="http://lifehacker.com/5899416/mac-flashback-trojan-find-out-if-youre-one-of-the-600000-infected">[Lifehacker Article]</a><br />
<br />
<h3>
RHEL/SL Update for RPM</h3>
Red Hat and Scientific Linux have both released updated RPM packages
to address an important vulnerability. It is
possible for maliciously made rpm files to compromise a system
before the rpm
signature is checked. More information is available here:
<a href="https://rhn.redhat.com/errata/RHSA-2012-0451.html">[Red Hat Announcement]</a><br />KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-91062954505242497922012-03-30T09:07:00.001-05:002012-03-30T09:07:30.928-05:00Moderate vulnerability in OpenSSL packagesNew OpenSSL packages have been released by Red Hat Enterprise Linux and Scientific Linux to address moderate level vulnerabilities that could be used for remote denial of service attacks and possibly decrypting encrypted messages.<br />
<br />
More information is available at the links below:<br />
<ul>
<li><a class="moz-txt-link-freetext" href="https://rhn.redhat.com/errata/RHSA-2012-0426.html">https://rhn.redhat.com/errata/RHSA-2012-0426.html</a>
</li>
<li><a class="moz-txt-link-freetext" href="http://listserv.fnal.gov/scripts/wa.exe?A2=ind1203&L=scientific-linux-errata&T=0&O=D&X=4ADC730E38161FDBDA&Y=listmgr%40fnal.gov&P=4960">http://listserv.fnal.gov/scripts/wa.exe?A2=ind1203&L=scientific-linux-errata&T=0&O=D&X=4ADC730E38161FDBDA&Y=listmgr%40fnal.gov&P=496</a></li>
</ul>KevDudehttp://www.blogger.com/profile/05132305358078917532noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-71394311782007482282011-08-24T11:02:00.006-05:002011-08-24T11:12:43.077-05:00<span style="color: rgb(204, 102, 0); font-weight: bold;font-size:130%;" >Thunderbird, FireFox and WebKit vulnerabilities fixed on Ubuntu and Fedora</span><span style="color: rgb(153, 0, 0); font-weight: bold;font-size:130%;" > </span><span style="font-size:130%;">
<br /></span>
<br /><span style="color: rgb(0, 0, 0);">Ubuntu has announced that security vulnerabilities affecting WebKit libraries have been fixed and users are encouraged to upgrade. The announcement can be found at http://www.ubuntu.com/usn/usn-1195-1/ </span>If a user were tricked into viewing a malicious
<br />website, a remote attacker could exploit a variety of issues related to web
<br />browser security, including cross-site scripting attacks, denial of
<br />service attacks, and arbitrary code execution. <span style="color: rgb(0, 0, 0);"> </span>WebKit is a web content engine, derived from KHTML and KJS from KDE, and used primarily in Apple's Safari browser. It is made to be embedded in other applications, such as mail readers, or web browsers.
<br />
<br />Fedora released a new version of FireFox and Thunderbird that fixes multiple security vulnerabilities. The details can be found at http://lists.fedoraproject.org/pipermail/package-announce/2011-August/064383.html
<br />Mine Altunayhttp://www.blogger.com/profile/05093575831341354756noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-30980311646145845512011-05-20T14:39:00.004-05:002011-05-20T14:44:28.631-05:00glibc vulnerability - privilege escalationThis is an announcement that should have been posted when it was sent to the site security contact in April. Posting now to make sure it's included on the blog for everyone.<br /><br />In coordination with the EGI CSIRT team.<br /><br />Title: HIGH risk glibc vulnerability - privilege escalation<br />(CVE-2011-0536) [EGI-ADV-20110412]<br />Date: April 12, 2011<br />Last update: April 12, 2011<br />URL: https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/glibc-2011-04-12<br /><br />Introduction<br />============<br /><br />A flaw has been found in the dynamic linker component of the GNU<br />C library. A local attacker could use this flaw to escalate their<br />privileges via a setuid or setgid program which is dynamically linked<br />to a library with certain properties.<br /><br />This vulnerability affects both RH5 and RH6 and their variants.<br /><br />EGI CSIRT considers this to be a HIGH vulnerability for now and might<br />raise it to CRITICAL if a working exploit is made public<br /><br />Details<br />=======<br /><br />The fix for CVE-2010-3847 introduced a regression in the way the dynamic<br />loader expanded the $ORIGIN dynamic string token specified in the RPATH and<br />RUNPATH entries in the ELF library header. A local attacker could use this<br />flaw to escalate their privileges via a setuid or setgid program using<br />such a library. (CVE-2011-0536)<br /><br />RH security team confirmed that reporter (of this vulnerability)<br />indicated an intention to make exploit public after waiting some time<br /><br />to give users and downstream distros an opportunity to pick up the fix.<br /><br />Mitigation<br />==========<br /><br />The only known mitigation is to apply the security patch from the software<br />vendor.<br /><br />Recommendations<br />===============<br /><br />It is STRONGLY recommended to immediately apply vendor patches when they<br />become available.<br /><br />Vendor patches are now available from<br /><br />* Ubuntu<br />* Debian<br />* RHEL5/6<br />* SL5/6<br /><br />To be released:<br /><br />* CentOS5/6<br /><br />References<br />==========<br />RedHat bugzilla:<br />https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-0536<br /><br />RHEL5 update:<br />https://rhn.redhat.com/errata/RHSA-2011-0412.html<br /><br />RHEL6 update:<br />https://rhn.redhat.com/errata/RHSA-2011-0413.html<br /><br />SL5/6 update:<br />http://listserv.fnal.gov/scripts/wa.exe?A2=ind1104&L=scientific-linux-errata<br />&T=0&P=583<br /><br />SLC5 update:<br />http://linux.web.cern.ch/linux/updates/updates-slc5.shtml<br /><br />SLC6 update:<br />http://linux.web.cern.ch/linux/updates/updates-slc6.shtml<br /><br />Debian update:<br />http://lists.debian.org/debian-security-announce/2011/msg00005.html<br /><br />Ubuntu update:<br />https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-January/0012<br />26.html<br /><br />Regards,<br /><br />Mingchao, EGI CSIRT security officer on dutyUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-30014830852299086442010-11-23T16:34:00.002-06:002010-11-23T16:37:52.373-06:00Various vulnerability notices and updatesThere is a vulnerability in the libsdp package which is used to enablean<br />application to communicate over the Infiniband SDP protocol instead of<br />ordinary TCP:<br /><br /><a href="https://bugzilla.redhat.com/show_bug.cgi?id=647941">https://bugzilla.redhat.com/show_bug.cgi?id=647941 </a><br /><br />Sites that use infiniband will want to look at the measures in the<br />notification above.<br /><br /><hr /><br /><br />Updated openssl packages that fix one security issue are now available for<br />Red Hat Enterprise Linux 6.<br /><br /><a href="https://www.redhat.com/security/data/cve/CVE-2010-3864.html">https://www.redhat.com/security/data/cve/CVE-2010-3864.html</a> <br /><a href="https://rhn.redhat.com/errata/RHSA-2010-0888.html">https://rhn.redhat.com/errata/RHSA-2010-0888.html</a> <br /><br /><hr /><br /><br />Updated systemtap packages that fix two security issues are now available<br />for Red Hat Enterprise Linux 5 and 6.<br /><br /><a href="https://rhn.redhat.com/errata/RHSA-2010-0894.html">https://rhn.redhat.com/errata/RHSA-2010-0894.html</a> <br /><br /><hr /><br /><br />There is a security vulnerability in PGP Desktop versions 10.0.3 and<br />earlier, as well as the upcoming 10.1 release. This vulnerability<br />may allow someone to spoof emails signed by the OSG security team.<br />For OSG users who use this version there is a knowledge base page,<br />as well as remediation steps at:<br /><br /><a href="https://pgp.custhelp.com/app/answers/detail/a_id/2290">https://pgp.custhelp.com/app/answers/detail/a_id/2290</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-6907031444262885022010-10-19T16:00:00.002-05:002010-10-19T16:03:13.365-05:00GNU libc vulnerabilityThe OSG Security Team wants you to be aware of a vulnerability impacting the glibc library.<br /><br />Introduction<br />============<br /><br />Tavis Ormandy recently released information about a vulnerability in GNU libc, complete with an exploit that on many systems can give any local user root privileges. (For full details, see the link below in the References section.)<br /><br />This vulnerability has been labelled CVE-2010-3847, and is present on many Linux distributions, including RHEL/CentOS/SL 5 (but *not* RHEL 3 and 4 and their derivatives). Vendor patches are not yet available.<br /><br />Details<br />=======<br /><br />As far as is known, the vulnerability can only be exploited if users can write to a file system that contains binaries with suid root permissions. (Since it is necessary for the attacker to create a hard link to a suid root binary.)<br /><br />This is, for instance, the case if /bin is located on the same filesystem as /tmp (or any other user writable location, like /var/tmp, /home, /var/lib/texmf, and so on). This is unfortunately a common configuration.<br /> <br />Mitigation<br />==========<br /><br />To make it impossible to make the required hard link, directories containing suid/sgid binaries can be made to appear to as separate file systems by doing<br /><br /> mount -o bind /sbin /sbin<br /><br />for each such directory.<br /> <br />Please note that these commands must be re-run whenever the system is rebooted, for example by adding them to a suitable init script.<br /><br />A baseline list of directories with suid/sgid binaries on a typical RHEL 5 system is:<br /><br /> /bin<br /> /sbin<br /> /usr/bin<br /> /usr/libexec<br /> /usr/lpp<br /> /usr/sbin<br /><br />You should check for any additional site specific locations using a command like<br /><br /> find / -type f \( -perm /u+s -o -perm /g+s \)<br /><br />that will list all files with suid/sgid permissions.<br /><br /><br />Recommendations<br />===============<br /><br />Apply the mitigation method above for all relevant locations.<br /><br />You may wish to suspend user logins and job submission until these steps have been taken; please refer to your local site policy.<br /><br />Apply vendor updates as soon as they become available.<br /><br />References<br />==========<br /> <br />[3]http://seclists.org/fulldisclosure/2010/Oct/257 <br /><br />The majority of this announcement was put together by Nuno Dias - EGI CSIRTUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-41167091403245170462010-09-29T17:51:00.002-05:002010-09-29T18:09:26.034-05:00Linux Kernel "snd_ctl_new()" Integer Overflow Vulnerability SA41650<span style="font-weight: bold;">From Secunia:</span><br /><a href="http://secunia.com/advisories/41650/">http://secunia.com/advisories/41650/</a><br /><span class="Apple-style-span" style="border-collapse: separate; color: rgb(17, 17, 17); font-family: Verdana,Arial,san-serif; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 14px; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span class="Apple-style-span" style="color: rgb(68, 68, 68); line-height: 13px;"><b>Description</b><br />A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to cause a DoS (Denial of Service) or potentially gain escalated privileges.<br /><br />The vulnerability is caused due to an integer overflow error when allocating memory within the "snd_ctl_new()" function in sound/core/control.c, which can be exploited to cause a heap-based buffer overflow.<br /><br />Criticality: Less Critical<br /><br /><span style="font-weight: bold;">OSG Recommendation:</span><br />If you think your systems may have this vulnerability you can consider removing or limiting access to the sound (or audio) subsystem.<br /><br /></span></span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-18767110785376043512010-09-22T10:36:00.002-05:002010-09-22T10:41:36.931-05:00Kernel updates for CVE-2010-3081The OSG security team announced last week an important kernel vulnerabilitythat affected 64 bit systems (announcement OSG-SEC-2010-09-16). Most of the vendors have now come out with patched kernels and the OSG security team is encouraging all sites to update any kernels that are currently affected.<br /><br />Here are the links or instructions to the patched kernels for the following OS versions:<br /><br /><span style="font-weight: bold;">RedHat</span><br />https://rhn.redhat.com/errata/RHSA-2010-0704.html<br /><br /><span style="font-weight: bold;">Fedora</span><br />https://admin.fedoraproject.org/updates/search/CVE-2010-3081<br /><br /><span style="font-weight: bold;">Scientific Linux</span><br />Dear SLC5 x86_64 (64 bit) platform users.<br />We have released in production a new SLC5 kernel addressing the locally exploitable security issue CVE-2010-3081. This kernel 2.6.18-194.11.4.el5 superseeds the "hotfix" kernel 2.6.18-194.11.3.el5.cve20103081 released last Thursday.<br /><br />In order to protect your system please apply urgently following update by running as root:<br /><br /># yum install kernel<br /><br />and if your system is an Xen virtual machine or hypervisor also run:<br /><br /># yum install kernel-xen<br /><br />and reboot your system for the update to take effect.<br /><br /><br /><span style="font-weight: bold;">Ubuntu</span><br />https://lists.ubuntu.com/archives/ubuntu-security-announce/2010-September/001159.html<br /><br /><span style="font-weight: bold;">SUSE</span><br />http://lists.opensuse.org/opensuse-security-announce/2010-09/msg00004.htmlUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-27518466017985833802010-04-29T18:08:00.003-05:002010-04-30T11:10:58.125-05:00RedHat xorg-x11-server important security vulnerabilityAn important vulnerability regarding RedHat xorg-x11-server has been<span style="font-weight: bold;"> </span>reported. The vulnerability could lead to a root-level compromise. RedHat has classified the severity level as "important" and detailed information is available at <a href="https://rhn.redhat.com/errata/RHSA-2010-0382.html">https://rhn.redhat.com/errata/RHSA-2010-0382.html</a><br />Although the vulnerability is not likely to affect the grid environment, we recommend all site admins to apply the patch on their systems as soon as possible for their site's protection.Mine Altunayhttp://www.blogger.com/profile/05093575831341354756noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-41504259685940757422010-03-18T16:09:00.010-05:002010-03-22T12:37:27.521-05:00Make sure your service is getting updates of CA certificatesWe have received information about storage services which had failed data transfers (FTS and srm services) because the CA certificates package has not been updated and the old CA package has an expired CA and not the new CA certificate that replaced the expired one.<br />The best way to update the CA certificates is using vdt-update-certs. Read about this and other important CA certificates information at <a href="https://twiki.grid.iu.edu/bin/view/Security/CADistribution">https://twiki.grid.iu.edu/bin/view/Security/CADistribution</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-12026795717751184462010-02-17T15:39:00.003-06:002010-02-17T19:11:52.856-06:00CRL update problems<p><br />As you probably know, CRLs are a vital part of the x509 security model; they are the only way CAs can invalidate compromised, or otherwise revoked certificates. Every time a user credential is presented to Grid-aware software, the appropriate CRL is checked to make sure the credential was not revoked.<br /></p><p><br />CRLs has expiration dates like everything else in the x509 world. A side effect of this is that if a CRL is not updated locally (by being downloaded from the CA site) before it expires, all credentials from that CA will be treated as invalid. So sites must download fresh updates frequently; the recommended policy in OSG is to do it once every 6 hours. The tool <span style="font-weight: bold;">fetch-crl</span> is used for the task.<br /></p><p><br />Several OSG site admins have notified us that fetch-crl occasionally fails to download a CRL one or more CAs, and has asked up (the security team) for guidance on what to do in those events.<br /></p><p><br />Ideally, we would like to debug each and every such event and make sure it is just a transient error, but given the distributed nature of the Grid this will not scale. OSG has hundreds of sites and there are hundreds of CAs, and problem is combinatorial. Unless such errors are very rare events, we need an alternative approach.<br /></p><p><br />One possibility would be for OSG to centrally serve the CRLs from all the supported CAs; this would allow us to more easily track problems since we can separately debug CA and site problems, thus going from a quadratical to a linear problem. Of course we still want to allow sites to go directly to the CAs for the CRLs if they want, for example when they are supporting a CA that is not part of the official OSG CA distribution; but we offer only limited support in such cases anyhow.<br /></p><p><br />However, the above solution is likely to create its own set of problems (still to be determined), so before we start any design and implementation effort we would like to know how important is to solve this for sites.<br /></p><p><br />Right now we don't even have clear statistics on how often sites have problems with their CRLs, nor if the problems are due to specific CAs. So input from sites is highly desirable.<br /><br /><br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-76938928873372557532010-01-21T15:14:00.003-06:002010-01-21T15:22:47.148-06:00Changes in new version of OpenSSLThis is an informational notice only, there is no current action that is needed to be taken for OSG sites.<br /><br />This is a notice that OpenSSL 1.x is changing the way they name the certificate files in the trust anchor store (the certificate files for grid middleware are usually stored in the "/etc/grid-security/certificates/" directory).<br /><br />Traditionally OpenSSL was using a MD5 hash for naming the certificate files (which would look something like 9ff26ea4.0). The new version has moved to using a SHA1 hash to create the certificate names. Installing the new openSSL version on a machine would mean that openSSL will NOT find the certificates installed in the trust stores due to different naming used by IGTF distribution. In short, the authentication on the installed machine will stop working. IGTF distribution has proposed changes which will fix this issue and a new distribution will be released once these changes have been completed.<br /><br />If you have other concerns related to this, please let us know. We are also investigating how other pieces of our distribution may be affected by this change.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-10908691872439928362009-12-18T15:05:00.007-06:002009-12-18T15:26:18.125-06:00Using p12 files with user commands (grid-proxy-init and voms-proxy-init)<pre wrap="" style="font-family:arial;">Most of the Grid users have been generally instructed to convert the p12 certificate files they get from CA on their browser to <span class="blsp-spelling-error" id="SPELLING_ERROR_0"><span class="blsp-spelling-error" id="SPELLING_ERROR_0">pem</span></span> format (i.e. <span class="blsp-spelling-error" id="SPELLING_ERROR_1"><span class="blsp-spelling-error" id="SPELLING_ERROR_1">usercert</span></span>.<span class="blsp-spelling-error" id="SPELLING_ERROR_2"><span class="blsp-spelling-error" id="SPELLING_ERROR_2">pem</span></span> and <span class="blsp-spelling-error" id="SPELLING_ERROR_3"><span class="blsp-spelling-error" id="SPELLING_ERROR_3">userkey</span></span>.<span class="blsp-spelling-error" id="SPELLING_ERROR_4"><span class="blsp-spelling-error" id="SPELLING_ERROR_4">pem</span></span>). This conversion requires the use of <span class="blsp-spelling-error" id="SPELLING_ERROR_5"><span class="blsp-spelling-error" id="SPELLING_ERROR_5">openssl</span></span> command <span class="blsp-spelling-corrected" id="SPELLING_ERROR_6">which</span> could be <span class="blsp-spelling-corrected" id="SPELLING_ERROR_7">challenge</span> to a novice Grid user. Users are not required to do this any more. Client commands used by most <span class="blsp-spelling-error" id="SPELLING_ERROR_8"><span class="blsp-spelling-error" id="SPELLING_ERROR_6">OSG</span></span> users (i.e. grid-proxy-<span class="blsp-spelling-error" id="SPELLING_ERROR_9"><span class="blsp-spelling-error" id="SPELLING_ERROR_7">init</span></span> and <span class="blsp-spelling-error" id="SPELLING_ERROR_10"><span class="blsp-spelling-error" id="SPELLING_ERROR_8">voms</span></span>-proxy-<span class="blsp-spelling-error" id="SPELLING_ERROR_11"><span class="blsp-spelling-error" id="SPELLING_ERROR_9">init</span></span>) are capable of accepting p12 certificates. Here are some instructions of how they may be used<br /></pre><ol style="font-family: arial;"><li>Make sure the p12 certificate has restrictive permissions (read-only by user i.e. 400)</li><li> Example invocations:<br /></li></ol><pre wrap="" style="font-family:arial;"><span style="font-size:100%;"><span style="font-family:courier new;"> <span class="blsp-spelling-error" id="SPELLING_ERROR_12"><span class="blsp-spelling-error" id="SPELLING_ERROR_10">voms</span></span>-proxy-<span class="blsp-spelling-error" id="SPELLING_ERROR_13"><span class="blsp-spelling-error" id="SPELLING_ERROR_11">init</span></span> -cert $HOME/.globus/mycert.p12 -key $HOME/.globus/mycert.p12 -<span class="blsp-spelling-error" id="SPELLING_ERROR_14"><span class="blsp-spelling-error" id="SPELLING_ERROR_12">voms</span></span> <span class="blsp-spelling-error" id="SPELLING_ERROR_15"><span class="blsp-spelling-error" id="SPELLING_ERROR_13">myVO</span></span></span></span><span style="font-size:78%;"><span style="font-size:100%;"><span style="font-family:courier new;"><br /></span></span></span><span style="font-size:100%;"><span style="font-family:courier new;"> grid-proxy-<span class="blsp-spelling-error" id="SPELLING_ERROR_13"><span class="blsp-spelling-error" id="SPELLING_ERROR_14">init</span></span> -cert $HOME/.globus/mycert.p12 -key $HOME/.globus/mycert.p12</span></span><br />The users can still continue using <span class="blsp-spelling-error" id="SPELLING_ERROR_17"><span class="blsp-spelling-error" id="SPELLING_ERROR_15">pem</span></span> certificates, this post is designed to make users and <span class="blsp-spelling-error" id="SPELLING_ERROR_18"><span class="blsp-spelling-error" id="SPELLING_ERROR_16">VOs</span></span> aware of an alternative that may remove some challenges experienced by our users and improve their overall experience of <span class="blsp-spelling-error" id="SPELLING_ERROR_19"><span class="blsp-spelling-error" id="SPELLING_ERROR_17">OSG</span></span>.</pre>Anandhttp://www.blogger.com/profile/11211609360437004601noreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-61621554199696147562009-11-17T11:48:00.002-06:002009-11-17T11:52:49.835-06:00New KCA (Kerberos certificate Authority) serverSince Monday morning Nov. 16, Fermilab has switched to a new KCA (Kerberos certificate Authority) server. The old KCA server will be dropped from IGTF CA distribution bundle on Dec 1st of 2009. The new server has a different public/private key pair, certificates issued by old KCA will not be valid.<br /><br />Site security contacts do not need to take any additional steps; a new bundle will be automatically fetched by your gatekeeper (if you enabled the cron jobs for fetching certificates -- see <a href="https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ComputeElementInstall#Install_the_CA_Certificate_Updat">https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ComputeElementInstall#Install_the_CA_Certificate_Updat</a>)<br /><br /><br />If you run web servers that uses Fermi KCA for authentication, please follow:<br /><br /> <a href="http://security.fnal.gov/pki/new2kcafaq.html#1_16">http://security.fnal.gov/pki/new2kcafaq.html#1_16</a><br /><br />which will explain how to properly update the web servers to accept the new certificates.<br /><br /><br />VO security contacts, if your users rely on certificates issued by Fermi KCA, you may get some questions from the users. There are basically two types of things that can go wrong:<br /><br />1) Users may experience some problems in getting certificates.<br /><br />In most cases this will be because the clients on their desktops which request the certificates have not been updated so that they can successfully talk to the new KCA software. Please direct users to the web page:<br /><br /> <a href="http://computing.fnal.gov/xms/Services/Getting_Services/Certificates/Certificate_Client_Update_Instructions">http://computing.fnal.gov/xms/Services/Getting_Services/Certificates/Certificate_Client_Update_Instructions</a><br /><br />which explains how to make sure their client software is properly updated. Users can go to the web page:<br /><br /> <a href="http://security.fnal.gov/pki/browsercerttest.html">http://security.fnal.gov/pki/browsercerttest.html</a><br /><br />to check whether or not they have a certificate (and whether it is one of the newly issued certificates).<br /><br />2) Users may have no problem getting certificates but discover that the certificates are not allowing them to access services that they were formerly able to access. In most cases this is because the service admin (typically not the user making the complaint) has not properly updated their servers to recognize the newly issued certificates. On grid machines that enabled automated cert updates, this should not be an issue. If problem persists, please open a ticket with OSG GOC.<br /><br />For any other problems, please urge your users to either submit a ticket to OSG GOC or directly call Fermilab Service Desk. Contacting Fermilab Service Desk may speed up the process.<br /><br />Regards,<br />OSG Security TeamUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-2518099536690330573.post-49569772072851018662009-11-09T15:39:00.003-06:002009-11-10T12:37:55.787-06:00OSG-SEC-2009-11-09Another linux kernel vulnerability has been discovered that could lead to a local root exploit. This is in reference to <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3547">CVE-2009-3547</a>, and there currently is proof-of-concept code that has been released. Security team contacts can view the information by looking at the following security notification ticket:<br /><br /> <a href="https://ticket.grid.iu.edu/goc/viewer?id=7720">https://ticket.grid.iu.edu/goc/viewer?id=7720</a><br /><br />If there are any questions on this notification ticket please contact the OSG security team.Unknownnoreply@blogger.com0