Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
  • Locked thread
Dr. Jackal
Sep 13, 2009


OneEightHundred posted:

Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero?

While the release for this might have been poorly managed, if this was a closed source bug we may have never found out about it. Depending on who found the exploit first, this could've been worse. There are embargo mechanisms that would allow these kinds of issues from being spread like wildfire, but it seems they release it earlier than planned (if you read the mailing list they mention extending the embargo).

Example of an existing embargo is what Amazon is currently doing, there are rumors that there is a massive Xen bug that is forcing them to have everyone migrate off of whatever instance they are on.

Adbot
ADBOT LOVES YOU

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Dr. Jackal posted:

While the release for this might have been poorly managed, if this was a closed source bug we may have never found out about it.
It's possible that attackers would have never found out either though.

I don't know how this could have been managed better though with an open-source program, which is the problem. It's not possible to release a source patch without revealing the problem, whereas a patch of a closed binary would probably get lost in a sea of other updates released at the same time, allow the embargo to extend for a much longer period while still distributing the fix, and reveal much less information about the specific vulnerability in the end.

The only way I can think of to discretely update something like Bash would be to, say, come up with an excuse to refactor the surrounding system to disguise the motive.

OneEightHundred fucked around with this message at Sep 26, 2014 around 06:32

evol262
Nov 30, 2010
#!/usr/bin/perl

Dr. Jackal posted:

While the release for this might have been poorly managed, if this was a closed source bug we may have never found out about it. Depending on who found the exploit first, this could've been worse. There are embargo mechanisms that would allow these kinds of issues from being spread like wildfire, but it seems they release it earlier than planned (if you read the mailing list they mention extending the embargo).

Example of an existing embargo is what Amazon is currently doing, there are rumors that there is a massive Xen bug that is forcing them to have everyone migrate off of whatever instance they are on.

Again, responsible disclosure was followed here. It's simply that the extent of the problem was larger than anticipated. The embargo would likely have been extended if they realized that the initial patch wouldn't do it.

distros@ is very good about coordinated release and embargoes (as a general rule that obviously isn't always true).

OneEightHundred posted:

It's possible that attackers would have never found out either though.

I don't know how this could have been managed better though with an open-source program, which is the problem. It's not possible to release a source patch without revealing the problem, whereas a patch of a closed binary would probably get lost in a sea of other updates released at the same time, allow the embargo to extend for a much longer period while still distributing the fix, and reveal much less information about the specific vulnerability in the end.

The only way I can think of to discretely update something like Bash would be to, say, come up with an excuse to refactor the surrounding system to disguise the motive.

A patch of a closed binary inevitably releases information about what else was wrong. You don't need to look any farther than Microsoft's updates to see that people reverse engineer them to see exactly what they're patching, then disassemble and diff binaries to see what it did. Obscurity is not a solution.

The embargo ended not because there was independent discovery (which generally ends it), but because they thought they fixed it. They didn't, obviously.

Additionally, "refactoring the surrounding system" to avoid disclosing major security problems is unethical. You're either proposing suggesting an RFE or code rework which gets a ton of (suspicious) mailing list traffic about its implications or a closed list discussing what to do about problems, which is antithetical to open-source ideals, obvious, or both.

There's always the option to quietly patch it and release an updated package which doesn't say exactly what you did or why (the bash commit messages are pretty awful anyway). This isn't done for a number of reasons, mostly ethics. I know the game development industry isn't big on those, but they're still a thing elsewhere.

Pudgygiant
Apr 8, 2004

Garnet and black? More like gold and blue or whatever the fuck colors these are

Does this affect Android? Because if so... gently caress.

Takes No Damage
Nov 20, 2004

The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. We live on a placid island of ignorance in the midst of black seas of infinity, and it was not meant that we should voyage far.


Grimey Drawer

I typed in that code from the first page and it just gives me a pointy bracket prompt:
>

and I have to ctrl+c back to regular. This is on a several-versions-old Lubuntu box tho so who knows what that means.

j883376
Aug 7, 2006


Linux Toddler!

Pudgygiant posted:

Does this affect Android? Because if so... gently caress.

Google apparently said no according to a CNN article.

http://money.cnn.com/2014/09/24/tec...-bug/index.html

Michaellaneous
Oct 30, 2013



It is not bad since there is appearently no code executed.
Except your shell is unable to show that code has been executed. But that is rather unlikely since it is an echo.

hifi
Jul 25, 2012



Takes No Damage posted:

I typed in that code from the first page and it just gives me a pointy bracket prompt:
>

and I have to ctrl+c back to regular. This is on a several-versions-old Lubuntu box tho so who knows what that means.

you missed a quote somewhere

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


evol262 posted:

Additionally, "refactoring the surrounding system" to avoid disclosing major security problems is unethical. You're either proposing suggesting an RFE or code rework which gets a ton of (suspicious) mailing list traffic about its implications or a closed list discussing what to do about problems, which is antithetical to open-source ideals, obvious, or both.
What's ethical is to minimize the damage done, and I don't really care for open source ideals if they aren't to that end either. The only real question is whether it would actually accomplish that goal or not.

XK
Jul 9, 2001

Star Citizen is everywhere. It is all around us. Even now, in this very room. You can see it's fidelity when you look out your window or when you watch youtube


Final (supposedly) patches are out now. I updated my stuff an hour or so back and none of the example demonstrations work any more.

code:
$ bash --version
GNU bash, version 4.3.26(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <[url]http://gnu.org/licenses/gpl.html[/url]>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
$ env X='() { (a)=>\' bash -c "echo date"; cat echo
date
cat: echo: No such file or directory
$ 

XK fucked around with this message at Sep 26, 2014 around 09:41

evol262
Nov 30, 2010
#!/usr/bin/perl

OneEightHundred posted:

What's ethical is to minimize the damage done, and I don't really care for open source ideals if they aren't to that end either. The only real question is whether it would actually accomplish that goal or not.

It wouldn't accomplish it, as you can trivially verify by watching people reverse OSX/Windows/Cisco updates.

It would he ineffective technically. It would open you to lawsuits (when some large bank or govt agency was left in the dark about what the problem was and how it occurred, then owned because they didn't update) unless we started publishing some huge security bulletin with sections like "how to mitigate" (if you can't patch) for every fix, and even Microsoft publishes information which gives a clear idea of how to exploit in CVEs. It's also unethical, but you clearly don't care about that.

What's ethical as a software vendor is to disclose your problems so people who are unable to patch for whatever reason (controlled environment, appliance, etc) have the possibility of stopping it somewhere through an ids or firewall or rewriting their own code or putting those boxes into a controlled access network or whatever (depending on the vuln).

It also covers your rear end legally.

This isn't "open source ideals" (though loving with the commit messages and having secret discussions about fixing problems in an open project is basic open source ethics), it's basic software practice that every major OS vendor follows.

Again, ethics may not be a big deal in the games industry. They are here.

Thanks, a developer for an OS vendor.

MrMoo
Sep 14, 2000



evol262 posted:

The problem isn't so much "through obscurity" as "almost nobody actually looks at this code and the people who do tend to miss it because they're so familiar with it that they don't have fresh eyes or they're looking to fix an unrelated bug, not security problems."

It's more of an issue of complex software being used for simple tasks and the consequences of insufficient test coverage. This is why the OpenBSD project creates a lot of new tools and breaks OpenSSH into smaller and smaller components to reduce the available attack vectors.

There is, I'm not sure whether it is a counterpoint or not, an alternative approach of promoting generic ease-of-use software and protecting with restrictive firewalls. But content firewalls are a far more challenging development than we are presently used to, but as processing power increases we may see more of in the future.

zergstain
Dec 15, 2005



Does this affect CGI scripts written in something that isn't bash that don't execute any shell commands? Do most scripts exec() something?

And my Mac is vulnerable, can anybody tell me why I should care enough to update bash without waiting for Apple?

evol262
Nov 30, 2010
#!/usr/bin/perl

zergstain posted:

Does this affect CGI scripts written in something that isn't bash that don't execute any shell commands? Do most scripts exec() something?

And my Mac is vulnerable, can anybody tell me why I should care enough to update bash without waiting for Apple?

Unless you have anything public-facing, your Mac is probably fine. Somebody somewhere is trying to use this to break out of JavaScript sandboxing in your browser, but don't worry about this for now.

Only you can say whether or not your scripts are safe. By testing adding headers.

MrMoo posted:

It's more of an issue of complex software being used for simple tasks and the consequences of insufficient test coverage. This is why the OpenBSD project creates a lot of new tools and breaks OpenSSH into smaller and smaller components to reduce the available attack vectors.

There is, I'm not sure whether it is a counterpoint or not, an alternative approach of promoting generic ease-of-use software and protecting with restrictive firewalls. But content firewalls are a far more challenging development than we are presently used to, but as processing power increases we may see more of in the future.

I'm all for breaking up code and openbsd has an excellent reputation for a reason, but it's hard to apply their methodology to actual use. Splitting up libraries and applications minimizes the attack surface, but we got here because people would rather have more features anyway (otherwise we'd still use sh), and they'll clamor for it.

Everyone would have to adopt the openbsd mindset, I think. Users included.

inignot
Aug 31, 2003

WWBCD?

Here are the vendor responses from Cisco, Juniper, and F5:

Cisco: http://tools.cisco.com/security/cen...a-20140926-bash
Juniper: http://kb.juniper.net/InfoCenter/in...ent&id=JSA10648
F5: http://support.f5.com/kb/en-us/solu...0/sol15629.html
https://devcentral.f5.com/articles/...h-big-ip-irules

Takes No Damage
Nov 20, 2004

The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. We live on a placid island of ignorance in the midst of black seas of infinity, and it was not meant that we should voyage far.


Grimey Drawer

OK I just apt-get upgrade'd my Lubuntu box from work and it looks like the fix is in:

before upgrade:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
$

after upgrade:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test
$

Success?

edit: forgot to ask, my old laptop is on Lubuntu 11.11 or some bullshit, I just keep it around to SSH/VNC into from work so I can do light browsing from the office. The only thing on it that's external-facing (that I'm aware of, not exactly a Linux guru) is SSH, does this pose a threat or is it only for higher level stuff like web servers etc?

Takes No Damage fucked around with this message at Sep 26, 2014 around 16:52

deimos
Nov 30, 2006

Forget it man this bat is whack, it's got poobrain!


I live dangerously:
salt '*' -b 25% pkg.upgrade

parid
Mar 18, 2004


VMware - http://kb.vmware.com/selfservice/mi...ernalId=2090740

Looks like the hypervisors are safe, but there are some individual confirmations that all their virtual appliances are vulnerable.

NetApp - https://library.netapp.com/ecm/ecm_get_file/ECMP1655016

All versions of DataONTAP. There goes my next couple of weeks.

KaneTW
Dec 2, 2011



code:
env X='() { (a)=>\' bash -c "echo date"; cat echo 
Still works on most systems. What a loving pain.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


evol262 posted:

It's also unethical, but you clearly don't care about that.
I'm hardly the first person to question whether full disclosure is ideal. I recall seeing one security researcher at some major security company basically flipping on the issue and suggest that public disclosure is largely enabling the problems that it claims to solve and recommended only disclosing to "responsible" parties, or not disclosing it at all if the vulnerable systems are due to be retired anyway. Retiring bash isn't realistic, of course, and full disclosure is certainly better than vendors not fixing the problems, but this is a question of what kind of information should go out when the problem IS being fixed.

quote:

Again, ethics may not be a big deal in the games industry.
I'm asking about this because I personally care about security quite a bit and would like to understand why this would or wouldn't be a good idea. It would be nice to get that information instead of this pointless "my dad can beat up your dad" thing you keep harping on, as if the field I'm in has anything to do with answering that question, and you're barking up the wrong tree anyway since the vast majority of my background is in an engine modding community with a deeply-ingrained culture of validating everything and fixing security issues immediately.

OneEightHundred fucked around with this message at Sep 26, 2014 around 17:38

evol262
Nov 30, 2010
#!/usr/bin/perl

OneEightHundred posted:

I'm hardly the first person to question whether full disclosure is ideal. I recall seeing one security researcher at some major security company basically flipping on the issue and suggest that public disclosure is largely enabling the problems that it claims to solve and recommended only disclosing to "responsible" parties, or not disclosing it at all if the vulnerable systems are due to be retired anyway. Retiring bash isn't realistic, of course, and full disclosure is certainly better than vendors not fixing the problems, but this is a question of what kind of information should go out when the problem IS being fixed.
Yet again, responsible disclosure was practised, but the scope of the vulnerability was larger than anticipated. distros@ is disclosure only to '"responsible" parties'

There's no sensible way to have only "responsible" parties carry on a discussion about what to do about now-public problems from a known-incomplete fix. Is there any reason not to have this discussion public? You're drawing conclusions from an extremely limited pool of samples where things went awry (Heartbleed actually worked exactly the way responsible disclosure is supposed to work when there's a risk there's an active exploit) and not the litany of cases you've never seen because the CVEs were embargoed and private until coordinated release happened, at which point disclosure occurred for the same ("how to mitigate if you can't patch") reasons.

You might wanna look into what responsible disclosure is and how it works, because there's a huge middle ground between full disclosure and no disclosure, and the former is only done when there's reason to believe attackers are or could be actively using the vulnerability.

It's absurd to talk about "vulnerable systems being retired". Talk to anyone who's walked through a datacenter at a major company or a bank and seen EOL/extended-support Win2k/XP boxes, OS/2, IRIX, old Sun pizza boxes hooked up to SCADA running water control systems for cities, etc. There's no such thing as "safe" systems or systems you know are going to retire unless you own every piece of hardware the vulnerable code is running on.

OneEightHundred posted:

I'm asking about this because I personally care about security quite a bit and would like to understand why this would or wouldn't be a good idea. It would be nice to get that information instead of this pointless "my dad can beat up your dad" thing you keep harping on, as if the field I'm in has anything to do with answering that question.

I don't know if it's your field or you specifically. This isn't "my speciality is better than yours". It's "you don't understand ethics at all". It's not a general sense of what's best in a given situation. Ethics follow maxims of best practice, ala Kant's categorical imperative. The idea is that you don't have a bunch of people making individual judgement calls for every situation where we disclose Heartbleed today because multiple researchers discovered it but not this vulnerability (which is potentially worse, is more widespread, and can lead to exactly the same kind of "I own everything your webserver can see" [plus more] problems) because...?

I would suggest you put a cursory amount of effort into looking into:

  • What comprises ethics, both from a philosophical and professional sense
  • What ethical practices other professionals (law, medicine, engineering) follow regarding disclosure, protection, etc
Then ask whether anything you've suggested (obfuscation of known vulnerabilities as "protection", nondisclosure of a widespread and widely-known security problem) could be construed as ethical in any way. If it helps, you can give yourself a "FISA court" or "warrantless wiretap" analogue, since you're suggesting the kind of invisibility those also include.

Scaramouche
Mar 26, 2001

SPACE FACE! SPACE FACE!

Someone has already built a botnet based around the Shellshock exploit:
http://www.theregister.co.uk/2014/0...ly_bash_botnet/

ukle
Nov 28, 2005


Nasty proof of concept to weaponise this bug via DHCP -

https://www.trustedsec.com/septembe...-proof-concept/

Run a DHCP server on the network that then forces a command via the exploit to each machine as it gets a lease, given that is usually run at root level its potentially limitless.

Just shows the potential damage for this exploit is far beyond what was first envisaged.

potato of destiny
Aug 20, 2005

Yeah, welcome to the club, pal.

FYI: If you're currently smugging out 'cause you're a windows admin, make sure you run a check for "bash.exe" on your servers and workstations, 'cause you might just discover that some of your shittier vendors like to install stripped-down Cygwin implementations!

MrMoo
Sep 14, 2000



KaneTW posted:

code:
env X='() { (a)=>\' bash -c "echo date"; cat echo 
Still works on most systems. What a loving pain.

Another update to bash was pushed that fixes this, bash 4.1-2ubuntu3.2 for Ubuntu 10.04 LTS

Lucid posted:

@ahyoomee:/tmp$ env X='() { (a)=>\' bash -c "echo date"; cat echo
bash: X: line 1: 期待してない token `=' のあたりにシンタックスエラー
bash: X: line 1: `'
bash: error importing function definition for `X'
date
cat: echo: そのようなファイルやディレクトリはありません

Michaellaneous
Oct 30, 2013



Nothing too much new on the news front except what you guys already mentioned. The first botnet attacked some us ministry, Mac wants to patch "soon".

H2SO4
Sep 11, 2001

put your money in a log cabin




Buglord

potato of destiny posted:

FYI: If you're currently smugging out 'cause you're a windows admin, make sure you run a check for "bash.exe" on your servers and workstations, 'cause you might just discover that some of your shittier vendors like to install stripped-down Cygwin implementations!

More like "Remember that virtual appliance you deployed? The one you forgot about? Surprise, motherfucker."

Scaramouche
Mar 26, 2001

SPACE FACE! SPACE FACE!

potato of destiny posted:

FYI: If you're currently smugging out 'cause you're a windows admin, make sure you run a check for "bash.exe" on your servers and workstations, 'cause you might just discover that some of your shittier vendors like to install stripped-down Cygwin implementations!

code:
C:\>dir bash.exe /S
 Volume in drive C has no label.
 Volume Serial Number is 64E4-CDDA
File Not Found

C:\>
Hopefully that covers it! You made me a bit twitchy there because I've been smugging it up everywhere.

evol262
Nov 30, 2010
#!/usr/bin/perl

Scaramouche posted:

Hopefully that covers it! You made me a bit twitchy there because I've been smugging it up everywhere.

Even if you have it on a Windows install, the odds of it doing anything which would lead to vulnerabilities is slim, so you can stay Though it's not like Windows has the greatest security record either...

spiny
May 20, 2004

round and round and round


Any word on how to test embedded devices like consumer routers / NAS devices ? Most ISP provided stuff doesn't allow (or support) a shell, so I can't use the check command, any ideas ?

edit, re-read that, if it's not clear, by 'embedded' I mean routers with a web interface etc

spiny fucked around with this message at Sep 26, 2014 around 21:41

Farmer Crack-Ass
Jan 2, 2001

~me reading your posts irl~


I'm still fuzzy on how this attack occurs. Can the attacker hit any system that's connected to a network?

H2SO4
Sep 11, 2001

put your money in a log cabin




Buglord

spiny posted:

Any word on how to test embedded devices like consumer routers / NAS devices ? Most ISP provided stuff doesn't allow (or support) a shell, so I can't use the check command, any ideas ?

edit, re-read that, if it's not clear, by 'embedded' I mean routers with a web interface etc

Find a CGI page and use an extension to shove the exploit into one of the headers

Factor Mystic
Mar 19, 2006

Baby's First Post-Apocalyptic Fiction

Scaramouche posted:

code:
C:\>dir bash.exe /S
 Volume in drive C has no label.
 Volume Serial Number is 64E4-CDDA
File Not Found

C:\>
Hopefully that covers it! You made me a bit twitchy there because I've been smugging it up everywhere.

The presence of bash.exe alone is still benign. You'll still need a thing that runs that thing and then sets environment variables from some other source. It'd be pretty odd to have a public CGI server running in cygwin bash.

evol262
Nov 30, 2010
#!/usr/bin/perl

H2SO4 posted:

Find a CGI page and use an extension to shove the exploit into one of the headers

If by extension, you mean curl.

curl -i -X HEAD "http://some.url" -A '() { :;}; echo "Warning: Vulnerable"'

H2SO4
Sep 11, 2001

put your money in a log cabin




Buglord

evol262 posted:

If by extension, you mean curl.

That's kind of a given, but we were just talking about Windows admins and they're usually more familiar with firebug or tamper data.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


evol262 posted:

Yet again, responsible disclosure was practised, but the scope of the vulnerability was larger than anticipated. distros@ is disclosure only to '"responsible" parties'
I can't find the article so I have to paraphrase, but in context, it was explicitly in contrast to public disclosure where the information would wind up in the hands of malicious parties as well. I found one that at least contains similar sentiments:
http://broadcast.oreilly.com/2009/0...re-is-irre.html

The core issue is that the overwhelming majority of attacks are not via zero-days, but via vulnerabilities unveiled by security researchers and deployed against users that haven't patched. The same article suggests that covert patching might be a good idea too, so I guess there's your answer to whether anyone would be consider it to be ethical.

It's probably better than vendors ignoring everything, sure, but the question is if it's possible to fix an issue without drawing attention to it.

evol262 posted:

It would open you to lawsuits (when some large bank or govt agency was left in the dark about what the problem was and how it occurred, then owned because they didn't update)
On what grounds? I can't find anything suggesting that nondisclosure has any impact on liability, and I can find plenty of people complaining about vendors not being liable at all, especially if they put liability waivers in the EULA like they always do. If liability waivers were disallowed by statute, then OSS would be obliterated.

unknown
Nov 16, 2002
Ain't got no stinking title yet!

Just a heads up - keep in mind, some "appliances" makers will reconfigure whatever repos away from the main OS maker's site, so things like "yum update" (or equiv) will be perfectly happy to not download the fixed version. Only way to truly know is to run the example code on every device possible.

This is going to be annoying for so long with all those weird-rear end legacy systems.

evol262
Nov 30, 2010
#!/usr/bin/perl

OneEightHundred posted:

I can't find the article so I have to paraphrase, but in context, it was explicitly in contrast to public disclosure where the information would wind up in the hands of malicious parties as well. I found one that at least contains similar sentiments:
http://broadcast.oreilly.com/2009/0...re-is-irre.html

The core issue is that the overwhelming majority of attacks are not via zero-days, but via vulnerabilities unveiled by security researchers and deployed against users that haven't patched. The same article suggests that covert patching might be a good idea too, so I guess there's your answer to whether anyone would be consider it to be ethical.

It's probably better than vendors ignoring everything, sure, but the question is if it's possible to fix an issue without drawing attention to it.

On what grounds? I can't find anything suggesting that nondisclosure has any impact on liability, and I can find plenty of people complaining about vendors not being liable at all, especially if they put liability waivers in the EULA like they always do. If liability waivers were disallowed by statute, then OSS would be obliterated.

Responsible disclosure is the context.

Whether or not one person considers covert patching OK has no impact on whether it's ethical. Again, go look up ethics and ethical standards (of care, of practice, etc).

The answer is yes, it is possible to covertly patch, but it is not ethical behavior, does not mitigate risk for clients, etc. Responsibility and misrepresentation (ala covert patching) are loaded terms in tort law.

EULAs are, as a rule, not binding contracts. Nobody cares what "people complaining" think. They care what lawyers think.

The thought from our legal team (which is broadly the legal stance of the industry) is that a challenge on the grounds of knowingly leaving vulnerabilities in critical infrastructure by failure to disclose would have significant legal repercussions if public services were affected, to say nothing of stock exchanges and everything on AWS, etc. No matter your opinion, our lawyers don't consider it ethical or worth it the risk.

Disclaimers of liability are hardly limited to open source.

MrMoo
Sep 14, 2000



MrMoo posted:

Another update to bash was pushed that fixes this, bash 4.1-2ubuntu3.2 for Ubuntu 10.04 LTS

Two more updates in Ubuntu for CVE-2014-7186 and CVE-2014-7187.

Adbot
ADBOT LOVES YOU

z0rlandi viSSer
Nov 5, 2013




at Cisco.

  • Locked thread