![]() |
Found it.
Linked to oracle client installations. You need to have an account on the machine and access to it. Fix has aready been pushed. |
BREAKING NEWS: The Pope is catholic.
Honestly BOAC. I've said it once and I've said it again. Software is written by human beings. The more lines of code in a piece of software, the greater the risk of bugs in the code. More complex pieces of software have a great number of interdependencies with other software written by other people (crypto libraries etc.). Mac, Linux, Windows .... even the infamous OpenBSD. Only an idiot would claim their software to be invincible, as time and time again, it's proven that it's not a case of if.... but when. What differentiates the software developers is not whether there are bugs in their code, but the overall quality of their code......how many bugs are found, the seriousness of the bugs, and how the bugs are dealt with etc. etc. |
Mixture - may I suggest you stop reading? Your news on the Pope is timely, however.:ugh:
|
BOAC the simple difference between this "security breach" and the microsoft ones is that the linux/unix ones are usually found by pro security firms. And its is very rare they are in the core kernal. They also tend to be package specific as in this case. Its not actually the linux kernal that has the security hole its a third party add on for oracle clients.
|
m j - according to my info the flaw IS in the Linux kernel and was introduced in version 2.6.30. The fix is at http://www.vsecurity.com/download/to...-rds-exploit.c. We may be looking at different things? This is the second recent kernel 'error' by the writers following September's.
|
Its in a protocol layer of RDS which is a data package protocol for operating databases eg Oracle. You have to be on the local machine with a local account to be able to use it. ie you the user have to want to get into your own machine. Any self respecting linux user would know if you want to zero the root passwd and have access all you have to do is boot via a liveOS and zero the root passwd in the passwd file. Its only really an issue if you have a work machine aka your a dealer on the stock exchange. Even if you do get the local admin rights you still have no access to the servers.
For this to be able to work the RDS services has to be up, in 99% of the linux machines it won't be turned on. The second flaw was part of the GNU C. libarys. And I might add as well there is no way I would ever open that link of yours. Its a C script that will screw every type of OS if it has something nasty inside it. Which again is the main issue with nastys, users clicking on things that they don't have a clue what they do. Call it security_update.doc.c. most folk won't spot the c. on the end click on it and trigger the script. |
MJ - to ease your concerns over whatever a 'c' is, you can visit VSR Security Advisories (no 'c')
|
C is a programing language.
And yes that is the "security flaw" which I was on about. |
Of course any computer is vulnerable if you have direct local access to it, or if you're silly about passwords. The book The Cuckoo's Egg documents various hack attacks on UNIX that took place in 1986, in which secure military systems were brought down by "human factors", such as weak passwords and "social engineering" (i.e. call someone up and ask for the password). There were also remote attacks such as the Morris worm, which exploited some known bugs in UNIX processes. When we talk about systems being vulnerable these days, we hope that people and designers have learned from these and other past vulnerabilities and closed them off, but of course it's not guaranteed.
One main difference between UNIX and Windows systems, in the past, has been that you had Windows users running with administrative privileges at all times, while the "root" user on a UNIX system was clearly defined as "only when you have to". You could log in as root and do work, but if you read any books or received any training, you were left in no doubt that that was a Bad Thing. If you're running e.g. a web browser, it should be running under your limited permissions, why would it need anything more? Normal UNIX users had no choice in the matter - permissions were enforced by the sysadmin. Which wasn't a problem at first, since UNIX systems were always designed to be run by a trained sysadmin, but if you're going to roll out UNIX (Linux, Mac OS X, etc.) to users who are not sysadmins, you have to give them a way in, which led to the "su" or "sudo" method. This gives you temporary root permissions using your own password, not a root password. You launch an application with "sudo" do what you have to do, and close the app. If any application were to try that, you get asked about it - is it necessary? If that sounds like what Microsoft has been doing with Vista and W7, it's not a coincidence. :8 |
BOAC
Mixture - may I suggest you stop reading? Anyhow, no I won't "stop reading".... I'm off to read a book. Thank you very much. |
bnt,
This gives you temporary root permissions using your own password, not a root password. You launch an application with "sudo" do what you have to do, and close the app |
Originally Posted by mixture
(Post 6028213)
Ah yes... the joys of "sudo su" .... :cool:
:} |
Obligatory sudo reference: xkcd: Sandwich
|
Linux...the Phil Collins of the IT world |
Originally Posted by mad_jock
(Post 6010985)
BOAC the simple difference between this "security breach" and the microsoft ones is that the linux/unix ones are usually found by pro security firms. And its is very rare they are in the core kernal. They also tend to be package specific as in this case.
That is, of course, still the situation with Flash bugs (nearly two weeks before they fix the latest critical exploit), but with Apparmor on Linux at least I can trivially sandbox Flash so that it literally cannot do anything bad to the OS because the kernel blocks it. |
Really Stuffed Now
I can't work out what is causing this problem, but over time the entire data disk fills up. Twice I have recovered the machine to a useable state by locating and deleting large directories, but this time I was too late and the machine has stuffed itself and now refuses to let me login.
I need to establish what the cause is, as there is clearly something amiss - and it isn't log files - they would never fill hundreds of Gbs in a number of weeks. Most importantly, however, I need to regain control of the server so that we can have our files back. I can gain access to the machine using a live disk (SuSe, or Knoppix), but they refuse to let me create a RAID using the existing pair of data disks; they want to format the disks, which clearly I don't want to do. A possibility is to disconnect the 2 data disks and reboot onto the OS disk, reset the partition tables, reboot and try to remount the data disks, but I am anxious that I risk losing my data. Thoughts anyone? And yes, the backup is fairly recent, but not that recent! |
Boot with Knoppix or whatever, take the data onto a separate USB drive, then blow away the server and reinstall so that you know how it's configured. Terabyte disks are relatively cheap these days, so ~£100 would get you a pair which you can RAID (assuming it's a SATA array rather than SAS?)
|
MB - Thanks for your thoughts, but I wish it were that simple. If I boot off a Live Disk, the partitioner recognizes the 2 disks as part of a RAID 1, but won't let me mount the RAID, saying that it cannot mount an unknown type of disk.
Is there a trick that I have missed? |
Originally Posted by N727NC
(Post 6062768)
MB - Thanks for your thoughts, but I wish it were that simple. If I boot off a Live Disk, the partitioner recognizes the 2 disks as part of a RAID 1, but won't let me mount the RAID, saying that it cannot mount an unknown type of disk.
Is there a trick that I have missed? Break the mirror and mount an individual disk (if you can)? |
What directories did you have to delete? I believe the / partition on my home server is about 16GB and I've never had this kind of problem.
|
| All times are GMT. The time now is 05:35. |
Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.