Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

SVG:SVG-CSIRT Critical Vulnerability Notes

From EGIWiki
Jump to navigation Jump to search
Main page Software Security Checklist Issue Handling Advisories Notes On Risk Advisory Template More

SVG-CSIRT Critical Vulnerability Notes

This is to help SVG and CSIRT jointly handle a critical vulnerability prior to following the approved procedure at SEC03

This is fairly general, and applies regardless of the source of the vulnerability, such as whether it is in the Middleware supplied in the EGI UMD or in an operating system.

Some of these notes may also be useful for 'High' risk vulnerabilities.

Consider Sending a 'Heads up'

This is optional, if quite a lot is known about the problem and it is likely that the team will send an advisory recommending what to do very shortly it might not be considered necessary. The purpose of sending a ‘heads up’ is to alert sites that the critical vulnerability exists. This should refer to any public announcements of the problem. (Often there are public announcements, and it is often because of public announcements or public exploits that the vulnerability has become classified as critical.) This should also warn sites to expect further instructions, such as the requirement to install updates urgently when they become available.

Send to site-security-contacts at and ngi-security-contacts at

Establish the effect of the exploit in the EGI Infrastructure

This may be very simple, such as by running a publicly available script any user authorized to use the Grid can get root. It may be more complex. This may already have been done by the SVG in the case of middleware issues reported to them, or it may already be readily available from some other source which is why the vulnerability has been assessed as ‘Critical’

Establish in what situation the vulnerability can be exploited

Establish which pieces of software and/or configuration are required in order for this to be exploited. This may e.g. involve establishing whether the exploit can be exploited on only one version of Linux, multiple versions, or only on sites configured in certain (possibly non-standard) ways. Various people may volunteer to test whether the exploit works in various circumstances, such as on a site they manage.

Establish how widespread the problem may be in the EGI Infrastructure

If the effect is only likely to occur on a small number of sites, it may be that it is better to simply handle it by contacting those sites and suggest they take appropriate action. If it affects a large number of sites, but not all sites, it is important to be clear about in what circumstances sites are affected.

Find out if or when a patch is likely to be available

In most cases, the Critical Vulnerability will be due to a software problem. If the Vulnerability is in the middleware supplied as part of the EGI UMD, then contact details will be available, and this task will probably already have been carried out by the EGI SVG. If the problem is in the operating system, then usually the SVG members who are also in CSIRT will chase the provider for a new version of the software.

Decide whether or not to wait for a patch

According to how long a patch is likely to be, decide whether or not to wait for a patch prior to recommending further action.

Find whether other action can mitigate or solve the problem

A small configuration change may be sufficient to prevent the vulnerability being exploited. If this is the case, establish what needs to be done in which circumstances. Test any changes that are recommended. Care should obviously be taken not to recommend a change in a hurry, which has no effect, prevents the site operating, or causes a worse problem than that it attempts to solve.

If interim action or mitigation is to be carried out

After testing, and no objections within CSIRT, write and send an initial advisory to sites including any recommendations for mitigation. You may use the AdvisoryTemplate to help make it easier to write. This will usually be sent as WHITE or GREEN.

GREEN should be the case if by recommending certain actions it reveals information that is not yet public which makes it easier for the issue to be exploited, or if the vulnerability has not been made public. Send to site-security-contacts at and ngi-security-contacts at

Follow approved procedure

When what final action sites should take to eliminate the vulnerability have been estalished write or update the advisory and follow the approved procedure at: SEC03

| RAT Issue Handling Instructions | RAT Issue Handling Templates | RAT Issue Handling Templates contd | SVG-CSIRT Critical Notes | Advisory Template |

| Issue Handling Summary | Reporters | SVG View | Software Providers | EGI MW Unit | Deployment | Notes on Risk |