the easiest is to put the drive as far down as you can get in the case
Interesting idea. I hadn't thought of that. For my computer, I mount my 3.5" hard drives in removable 5.25" drive bays. The bays are made of aluminium to help dissipate the heat, and they have a small fan in the back to help circulate the air away from the drive. Of course, the only 5.25" drive bays in my case are at the top of the machine.
I originally bought the drive bays years ago because I noticed how much heat there was between my two drives. Given that there was only a couple millimeters of space between them, the heat had a difficult time escaping. I wanted to put more space between the drives, but my only 3.5" bays were taken by the hard drives and a floppy drive.
The drive bays cost me about $50 each (I bought two), which seemed expensive, but as I think about it, I've never had a hard drive fail on me. These days, you can get similar drive bays for $10-$20 each.
However, no one will ever go back to 2GB hard drives for the same prices as a 200GB hard drive, nor will anyone want to go that far back in proportion to Moore's law in the future in exchange for giving up their mechanical hard drives.
Along the same lines, nobody will ever adopt semiconductor memory in favor of core memory. I mean, sure, it's faster (80ns vs 1000ns), but at the extraordinarly high price and lower capacities, nobody will ever take it seriously. Trust me, when we have a megabyte of core memory for a few thousand dollars, people will use it.
Or so the reasoning goes. History always seems to repeat itself.
Say what you will about the limited hard drive space, but the Amiga could do more with 170MB back then than most computers can do with 170GB today. It was very efficient with regards to disk space.
I used to know a guy who set up kiosks and displays for movie theaters using Amiga hardware. He had systems that allowed people to interactively search and view movie times, view movie trailers (from a laser disc), and do all kinds of fancy overlays and screen wipes. All this for an entire theater, including the OS, software, graphics, and data, would only fill about 10MB of disk space. How much do you think it would take these days to do the same thing?
'Anything you can make for $100, we can make for $40'
I can produce $100 bills for $100 each. If I can purchase some from you for $40 each (and I want real US $100 bills, not those cheap counterfits), I will buy all you have.
Hmmm... but I guess you guys don't actually make money, do you?
But fopen isn't a system call. It's a ANSI library function that wraps the real system call (in the case of Unix, open). What I'm getting at is that by using LD_PRELOAD, you can write your own fopen and have it execute in place of the one in libc. Then you can make it do whatever you want, including creating a root shell.
Now in the case of OpenBSD's idea, you're right. Since only system calls can get elevated privileges, this kind of attack won't work. That's why I like their idea.
This sounds similar to an idea I've floated around to a few people, except that my idea worked on library functions. The idea was to allow setuid and setgid on individual functions instead of entire programs. When you called such a function, it would run with the elevated privileges determined by the ownership of the library file itself, and when it returned, permissions would go back to what they were previously.
The one issue I had with this was what to do if a setuid function called another function. Should the privileges be passed onto the extra function? At first thought, it seems like it should, but consider this example:
I have a library called libprivfunctions.so. Within this library is a function to open a privileged file:
We'll say this function is set to run as a setuid root (maybe/etc/priv.conf can only be read by root). An attacker could execute a
export LD_PRELOAD=/home/attacker/libc.so
before running a program linked against libprivfunctions.so. This version of libc.so would have a fopen that creates a root shell. When open_priv_file() is called, it will call the falsified fopen which, if run as root, will breach the security of the system. Maybe the easiest way around this would be to disallow any LD* variables when running programs linked against setuid/setgid functions (similar to the way setuid/setgid progams work). But the logic behind this gets complicated (you don't know if you're linking against setuid functions until after you've linked. But what if that outcome was caused by one of the LD* variables?).
I would say that allowing elevated privileges to just system calls is a good way around this problem. Hats off to OpenBSD for another sound decision.
If someone can get a root shell, even if it's in a chrooted jail, they can get access to your whole system. This is possible because chroot wasn't really designed for security purposes, even though it's usually used that way. A root user can break out of a jail because:
1) chroots are not recursive. If I create a chroot jail inside an existing chroot jail, the outer jail disappears. Combine this with #2.
2) chroots will not let you open a file outside the jail. But if a file is already open when the jail is created, it will remain open and active.
So, if I can get a program to the victim's machine, I can open a file descriptor to the current jailed directory (fd = open(".", O_RDONLY)), mkdir a subdirectory, change into that directory, and chroot in it. Now I can do a fchdir(fd) to get out of the jail. From there, I will perform several chdir("..") calls to reach the real root directory, and exec a bin/sh. I now have a root shell to the whole system.
An ordinary user can't do the chroot's, but if there's already on open file handle pointing outside of the jail, they can usually break out, too.
Heh. This reminds me of the '90s song "Banditos". It had the following lyrics in the chorus:
Well give your ID card to the border guard Now your alias says you're Captain Jean-Luc Picard Of the United Federation of Planets 'Cause he won't speak English anyway
Yes, it is a violation of the DMCA. It means that humans can now be declared as circumvention devices. In other words, being human is now illegal, and you can be thrown in jail for 20 years for it.
If anyone asks, I'm not human. But I think my coworkers already knew that.
One of the most visible and important parts of the Aqua interface are high-quality icons. Mac OS X icons have rich visual characteristics: They are often displayed at a sizes varying from 128 x 128 pixels to 16 x 16 pixels, can contain millions of colors, have very realistic qualities, and are professionally rendered.
Someone help me with this. If I have an icon that's 128x128, how can it contain millions of colors when it only has 16384 pixels? Does it have color cycling or something?
If you're making a pass through a program and see a variable, then you have to replace it, period. The only variables that have been converted have already been passed by your parser. So you would want to convert every variable you come to. Deciding what to convert it to is accomplished by a table.
To answer the original question, if you come across a variable VAR######, you would convert it just like any other variable. As an example, suppose I have a program with these 3 variables:
loop
sum
VAR000001
They could be converted like this:
loop --> VAR000001
sum --> VAR000002
VAR000001 --> VAR000003
What if you had no money, and your family and kids were starving to death? It's winter, you don't make enough money at your job to give your kids any shelter or food, and they're out hiding in the dumpster behind McDonald's trying to fend off frostbite while getting some free food.
According to the article, the company is pulling in a million dollars a month. I don't think they're starving to death, lacking in shelter or food, or hiding in the dumpsters behind McDonalds.
Slashdot Mirror
the easiest is to put the drive as far down as you can get in the case
Interesting idea. I hadn't thought of that. For my computer, I mount my 3.5" hard drives in removable 5.25" drive bays. The bays are made of aluminium to help dissipate the heat, and they have a small fan in the back to help circulate the air away from the drive. Of course, the only 5.25" drive bays in my case are at the top of the machine.
I originally bought the drive bays years ago because I noticed how much heat there was between my two drives. Given that there was only a couple millimeters of space between them, the heat had a difficult time escaping. I wanted to put more space between the drives, but my only 3.5" bays were taken by the hard drives and a floppy drive.
The drive bays cost me about $50 each (I bought two), which seemed expensive, but as I think about it, I've never had a hard drive fail on me. These days, you can get similar drive bays for $10-$20 each.
However, no one will ever go back to 2GB hard drives for the same prices as a 200GB hard drive, nor will anyone want to go that far back in proportion to Moore's law in the future in exchange for giving up their mechanical hard drives.
Along the same lines, nobody will ever adopt semiconductor memory in favor of core memory. I mean, sure, it's faster (80ns vs 1000ns), but at the extraordinarly high price and lower capacities, nobody will ever take it seriously. Trust me, when we have a megabyte of core memory for a few thousand dollars, people will use it.
Or so the reasoning goes. History always seems to repeat itself.
Say what you will about the limited hard drive space, but the Amiga could do more with 170MB back then than most computers can do with 170GB today. It was very efficient with regards to disk space.
I used to know a guy who set up kiosks and displays for movie theaters using Amiga hardware. He had systems that allowed people to interactively search and view movie times, view movie trailers (from a laser disc), and do all kinds of fancy overlays and screen wipes. All this for an entire theater, including the OS, software, graphics, and data, would only fill about 10MB of disk space. How much do you think it would take these days to do the same thing?
Surely this is a "dec", not a "codec"
Nah. These days it's called a "Compaq".
Oh, okay. I'll use MSMonkeyBoy from now on.
'Anything you can make for $100, we can make for $40'
I can produce $100 bills for $100 each. If I can purchase some from you for $40 each (and I want real US $100 bills, not those cheap counterfits), I will buy all you have.
Hmmm... but I guess you guys don't actually make money, do you?
The article's subject says is all. I would assume if the PC is dead, it would be silent as well.
If you type GET LOST on a Commodore 64, it will respond with ILLEGAL DIRECT,
But fopen isn't a system call. It's a ANSI library function that wraps the real system call (in the case of Unix, open). What I'm getting at is that by using LD_PRELOAD, you can write your own fopen and have it execute in place of the one in libc. Then you can make it do whatever you want, including creating a root shell.
Now in the case of OpenBSD's idea, you're right. Since only system calls can get elevated privileges, this kind of attack won't work. That's why I like their idea.
This sounds similar to an idea I've floated around to a few people, except that my idea worked on library functions. The idea was to allow setuid and setgid on individual functions instead of entire programs. When you called such a function, it would run with the elevated privileges determined by the ownership of the library file itself, and when it returned, permissions would go back to what they were previously.
/etc/priv.conf can only be read by root). An attacker could execute a
The one issue I had with this was what to do if a setuid function called another function. Should the privileges be passed onto the extra function? At first thought, it seems like it should, but consider this example:
I have a library called libprivfunctions.so. Within this library is a function to open a privileged file:
FILE *open_priv_file(void) {
return fopen("/etc/priv.conf", "r");
}
We'll say this function is set to run as a setuid root (maybe
export LD_PRELOAD=/home/attacker/libc.so
before running a program linked against libprivfunctions.so. This version of libc.so would have a fopen that creates a root shell. When open_priv_file() is called, it will call the falsified fopen which, if run as root, will breach the security of the system. Maybe the easiest way around this would be to disallow any LD* variables when running programs linked against setuid/setgid functions (similar to the way setuid/setgid progams work). But the logic behind this gets complicated (you don't know if you're linking against setuid functions until after you've linked. But what if that outcome was caused by one of the LD* variables?).
I would say that allowing elevated privileges to just system calls is a good way around this problem. Hats off to OpenBSD for another sound decision.
If someone can get a root shell, even if it's in a chrooted jail, they can get access to your whole system. This is possible because chroot wasn't really designed for security purposes, even though it's usually used that way. A root user can break out of a jail because:
1) chroots are not recursive. If I create a chroot jail inside an existing chroot jail, the outer jail disappears. Combine this with #2.
2) chroots will not let you open a file outside the jail. But if a file is already open when the jail is created, it will remain open and active.
So, if I can get a program to the victim's machine, I can open a file descriptor to the current jailed directory (fd = open(".", O_RDONLY)), mkdir a subdirectory, change into that directory, and chroot in it. Now I can do a fchdir(fd) to get out of the jail. From there, I will perform several chdir("..") calls to reach the real root directory, and exec a bin/sh. I now have a root shell to the whole system.
An ordinary user can't do the chroot's, but if there's already on open file handle pointing outside of the jail, they can usually break out, too.
Boucher vowed to strike out the repressive portions of the DMCA
So he's vowed to completely eliminate the DMCA then?
Heh. This reminds me of the '90s song "Banditos". It had the following lyrics in the chorus:
Well give your ID card to the border guard
Now your alias says you're Captain Jean-Luc Picard
Of the United Federation of Planets
'Cause he won't speak English anyway
You have a girlfriend? You're obviously not the kind of geek they're talking about, then.
Yes, it is a violation of the DMCA. It means that humans can now be declared as circumvention devices. In other words, being human is now illegal, and you can be thrown in jail for 20 years for it.
If anyone asks, I'm not human. But I think my coworkers already knew that.
From the article:
One of the most visible and important parts of the Aqua interface are high-quality icons. Mac OS X icons have rich visual characteristics: They are often displayed at a sizes varying from 128 x 128 pixels to 16 x 16 pixels, can contain millions of colors, have very realistic qualities, and are professionally rendered.
Someone help me with this. If I have an icon that's 128x128, how can it contain millions of colors when it only has 16384 pixels? Does it have color cycling or something?
But to lose it all on SJ means that they really did have squat
But this is where you're wrong. I just checked and couldn't find any indication they had squat. It was completely absent from the proceedings.
No, you got it all wrong. The story said "factor large primes *in seconds*". Yours works in microseconds. Better to do it like this:
int factorLargePrime( int largePrime ) {
sleep( 2 );
return largePrime;
}
If you're making a pass through a program and see a variable, then you have to replace it, period. The only variables that have been converted have already been passed by your parser. So you would want to convert every variable you come to. Deciding what to convert it to is accomplished by a table.
To answer the original question, if you come across a variable VAR######, you would convert it just like any other variable. As an example, suppose I have a program with these 3 variables:
loop
sum
VAR000001
They could be converted like this:
loop --> VAR000001
sum --> VAR000002
VAR000001 --> VAR000003
Get it?
Turbolinux Not Dead Yet
Of course not. That won't happen until tomorrow, silly.
You know, bad paper holds about a hundred years only; good paper may hold much longer, but only if stored well
Just bury it in a landfill. It'll last forever in there.
...why do drive-up ATMs have brail on the buttons?
Oh MAN! You just ruined the whole trailer for me! I guess there's no point in going to see it now.
:-)
What if you had no money, and your family and kids were starving to death? It's winter, you don't make enough money at your job to give your kids any shelter or food, and they're out hiding in the dumpster behind McDonald's trying to fend off frostbite while getting some free food.
According to the article, the company is pulling in a million dollars a month. I don't think they're starving to death, lacking in shelter or food, or hiding in the dumpsters behind McDonalds.