It may sound funny, but the MIT Kerberos sources contain an version of telnet and telnetd that support encryption. There has not been a vulnerablity in that for a while that I know of. There was a stupid vulnerability in logind on Solaris though which that telnet used. Also there is an encrypted version of rsh, rshd, and klogind in that source code. That has not been anything reported on that in a while either, though I think you only get 3DES if I recall correctly.
They mention Debian and 4.7p1 since that is what the researchers targeted. It was not fixed until 5.2. For various reasons Debian will not go past 4.7 for a while yet.
The flaw is in the RFC since 4251 says that the server has to communicate the fact that there was an error. OpenSSH would communicate that as soon as it noticed. By the attacker replaying data slowly it could figure-out out bits in the plaintext. Now OpenSSH waits until it gets a lot of data before it responds. See not every implementation needs to be vulnerable by following the RFC, but they are if they follow it in the naive way.
In fact it could have been much worse. Measures could have been taken to reestablish the connection after the error. In the OpenSSH implementation the connection is dropped on the first such error. But there were (as yet undisclosed) implementation details in OpenSSH that improved the odds of success from the theoretical 2^-18 to 2^-14.
5.1 is vulnerable. If you cannot upgrade just disable all CBC mode ciphers on your server. Some clients will not be able to negotiate a ciphersuite then and the connection will fail for those. If you need CBC for those reasons upgrade or back port.
Basically only CBC is vulnerable, so they prefer others. Also they now read the maximum size before returning an error. There still is a very slight information leak from timing analysis but it would make the chances much much smaller, to the point that it is now an infeasible attack:
* This release changes the default cipher order to prefer the AES CTR
modes and the revised "arcfour256" mode to CBC mode ciphers that are
susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".
* This release also adds countermeasures to mitigate CPNI-957037-style
attacks against the SSH protocol's use of CBC-mode ciphers. Upon
detection of an invalid packet length or Message Authentication
Code, ssh/sshd will continue reading up to the maximum supported
packet length rather than immediately terminating the connection.
This eliminates most of the known differences in behaviour that
leaked information about the plaintext of injected data which formed
the basis of this attack. We believe that these attacks are rendered
infeasible by these changes.
Not really, there are not enough sensors to narrow it down enough. A competent tech knows what to do next to diagnose anyway and does not need any AI to help. You also always have to imagine that the sensor is bad as well. In fact that is why there are often more than one of each sensor.
I'm in sort of a similar predicament here at work. A few years ago I did the software for some hardware replacement. Think industrial controls. A year later they wanted diagnostics like that. The old system was like that, since the field bus was so primitive. Basically no communications meant go replace the module with a spare. Now things are much more complicated. There is a remote box, then there is a fiber or serial cable to a PMC (like small PCI) card. That then is on a VME processor board with an ethernet jack. That goes into a switch, and a whole mess after that. There is another computer in the control system that is a consolidator/gateway. Then there is the console that gets run over X11 (through an ssh gateway) on some PC. You can see how when I get an error like request timed-out it is now basically impossible to say where the problem occurred (it is most likely not the hardware).
But they wanted something, so I made a procedure. It is essentially this:
Do a remote reset over the network of the remote unit. Do a remote reset over the network of the VME crate. Go out to the remote unit with a kit (I put it together). Press the reset button. Put on the dongle, press the reset button. (The dongle being present clears the NVRAM on reset, there is a lot more you can do over the serial interface though.) Go to the VME crate, cycle power. Replace the fiber or serial cable (in the kit). Replace the remote unit (in the kit). Replace the PMC (in the kit). Call the tech on the call-in list (could be me).
Whatever you replaced bring back, a tech will look at it then during normal work hours.
I've done Dodge, Volvo, Mazda, Ford, and Chevy. When I needed to deal with VW I had to use a better reader that my tech friend had access to. It is neat the stuff that you can get off of the VAG on a notebook. There are all these curves plus it is a lot like a PLC and for various modules you can set parameters that are essentially 16-bit words exported in the address space of every module. Still it only tells you such and such a sensor detected this and you need to use instinct, gut, and experience to figure-out why.
I'm lucky. I had a very frugal father. He bought only GM cars when I was a kid in the US. Mostly SBC but there was an Olds 307 and a Buick 350 (also a Ford Grand Torino, but it was such a mess he gave it to my uncle who sold it quickly). In the '80s we had used cars from the '70s to give an idea. I was always curious and around him (even when very young and he worked on a pair of Skodas in Austria and a Ford Tractor in Poland). In the second grade I helped him rebuild a small Briggs and Stratton (I was the gopher, go-fer that wrench, etc). Then in the fifth grade I rebuilt the same small engine over two evenings with him looking over my shoulder from time to time. Then I helped him and my uncle more and more with the cars. My mother worked for an OEM soldering electronics and building wiring harnesses. My aunt and uncle worked as auto mechanics and later my uncle started a parts store. My aunt would rebuild alternators, starters, transmissions, etc for him. My father was an engineer but in aerospace/defense. By the time I had my first beater I had a lot of help and enough experience to get into trouble. I loved it. In 2004 I bought a new car for the first time for my wife. A few years later I sold the Mazda and bought a new car of my own. I've done a lot less work since then. I really miss it, though free weekends and evenings are nice and I know some former neighbors very much did not like my working on the Mazda and Volvo (the last of my project/daily driver cars).
Sometimes you get different code sets depending on the region your car is initially sold in (different code in the firmware that runs different monitors) or where the ABS module was from Bosche or another later cheaper OEM.
The other thing is that a local mechanic can do the work and submit it as warranty work for almost all cars. They need to do some paper work, but they generally like it since the manufacturer lets them say that it even took more than the book time that dealer service gets to quote. This is the case precisely since there are some cases where a dealer service center is just too far away. Sometimes oyu have to pay for a really expensive tow though.
Lots of cars were like this. I had a Mazda with with a few terminals. There was a screw to ground a pin to reset the codes. Another terminal you could put an multimeter prong in when you grounded another pin with the same screw. Then you watched the needle for the codes.
I had a Volvo that had a little box with a LED and a couple of buttons, very simple. These were early OBD-II cars.
Oh you lack experience, it could be lots of other things. Semi often I have seen a gummed-up PCV valve. Was that the cause though? Nope how did it get that way? Why bound or worn piston rings. That let too much blow back into the crank case. The oils gummed-up the valve, then the gas vapors go right back in the cylinder constantly, making it rich.
What evidence did I have other than a small LCD screen for this back in the day? The valves made a characteristic sound from the carbon deposits and the oil looked black soon after being changed. Lots of things can cause those, but it is just another piece of the puzzle.
Reseat the valve, replace the PCV valve and the piston rings, then things were great. (Well you had to adjust the carb(s) too of course.)
OBD-II (the UART mentioned in the article) does not really tell you what is wrong with your car. It gives you another clue. Experience, know-how, tools, other clues, and a process of elimination tells you what is wrong with your car. OBD-II tells you that something was detected like a knock, misfire, oxygen rich, emissions leak, etc. Now a mechanic has to hunt down the cause and fix that. I just wanted to make that clear. It is like looking at iostat not dtrace.
It will be nice to get the codes, but most of them are pretty much known by now. Some ranges are pretty defacto standard too. It's annoying though that the codes can be different on the same model car sold in CA vs IL though. That can trip you up when you have a code list that does not include the correct region.
Cisco got into trouble about this when they bought linksys which made some hardware that used GPL stuff. They used linux, uLibC, BusyBox, Zebra, and other projects. Then they were contacted and they released source that was not really the source used. They then basically corrected that. Then this situation kept repeating a few times.
If you were worried about security, there was a bug in an web page used for ping that let you run arbitrary commands as root on a whole bunch of hardware. This was figured-out before any source was ever released. The thiobor line of firmware for a long time was just a improved version of what linksys provided. When cisco bought linksys they quickly made a vxworks based router/ap to not have to deal with the OSS stuff. There are no secrets in this stuff that has been released like you worry about. It is not IOS.
I bought a student version of Borland C/C++ back in the day. It cost $400. One stipulation in the license was that I could only use the tools for educational purposes. Various things were explicitly called-out as prohibited. One was selling software that I built with the tools. I also could only demo my software under certain conditions. The cheapest version of Borland without such restrictions was $1000 at the time. This was the one without much support, no DB stuff (pre dBase, was that Fox), no extender (was it pharlap that Borland bundled back then), no Pascal (pre Delphi), etc. Some things are nicer in this day than back then.
Two are local to the same machine for admin users, one is to other machines on the network that have been previously logged in to in various ways for any kind of user.
One problem is that the majority of OS X users run as an admin user. Look at the permissions on say/Applications, trivial to drop a trojan there that some one else later runs. Also I see that the permissions are also screwed-up on many machines. I just took a look at/Applications/Safari.app/Contents/MacOS/Safari on one machine and I see that any admin user can rewrite it to anything they like. In fact it may be typical for Applications to be like that for all I know.
Another problem is that Apple has adopted kerberos for use like people would use ssh-agent on other unix-alikes so any networked machine they had recently been on the code an get to without a new password prompt. The output of klist also gives oyu hints of what hosts to try. This makes it easier to spread from one machine to the next.
In college one of my computers was a notebook that had Cirrus Logic graphics with 1MB of VRAM. Unfortunately the DACs were slow so the refresh at 1024x768 was very slow (intended for interlaced mode). I ran Linux with Xfree86 in a peculiar resolution that I think was 1120x704 (yes it was not square on my monitor, your brain gets used to it though) because the horizontal retraces took a lot of valuable time and I was able to eek about a 10% higher refresh rate (almost 50Hz, okay with mostly black backgrounds) that way. That left me about 256K of extra VRAM. I used a portion of that to make the screen a bit virtually taller and wider for my icons in fvwm (xterms on the right going down, some special apps in a box on the right at the bottom, and everything else along the bottom) plus everything else was used by the Xserver to cache frequently used pixmaps. So I was using all of that 1MB. I tried very hard to get the LCD and external monitor to work in non mirrored mode, but was never able to tweak the X driver for that (it worked in Windows, that would have been another way to use all the VRAM), the CL documentation was full of errors. I did get 16-bit (really 15-bit, one bit was an 'alpha bit' used in accelerated bitblt routines provided by the chip) to work in SVGAlib though which was not even in the Windows driver. It was very incompatible with another person's card though so it never got accepted.
Did you have something like a 80-100MHz 386SX because "7th Guest" ran just barely on my 33MHz 486DX with very expensive 128K of cache on the motherboard (that was very peculiar back then). I also had a 1MB Trident 16-bit ISA SVGA card, that bus really hampered video performance. That was good enough for 256 colors at 1024x768 and the clock was really slow so the refresh was very low. To really run that game you needed at least a 50MHz 486DX (assuming the typical no extra cache) and a VLB video card (yes they did make VLB on 486 as well for a while).
Back then some cards could do 24-bit at 640x480 and 15-bit/16-bit at 800x600 and 2MB cards were just around the corner. Also the address space of ISA is only 16MB, it would really be hard to use a 128MB ISA card. In fact towards the end every program I had used my Trident card with a 64K window into the framebuffer since I eventually had 20MB of RAM and the memory controller could not deal with those bus addresses conflicting.
A lot of PID loops do this sort of average in the I term. Choose your constants right the stale data becomes meaningless soon. No it is not an average but is commonly called that.
What about the large portion of the population that have 'minor constriction' indications if they take a spirometer test, does the breathalyser flag the reading as potentially invalid? About one in five adults have a minor constriction.
Look-up a bunch of cheap hosting providers. How many have postgres? How many have mysql? See why you might choose mysql over postgres (or db2 or sysbase or oracle) for non-technical reasons?
Slashdot Mirror
It may sound funny, but the MIT Kerberos sources contain an version of telnet and telnetd that support encryption. There has not been a vulnerablity in that for a while that I know of. There was a stupid vulnerability in logind on Solaris though which that telnet used. Also there is an encrypted version of rsh, rshd, and klogind in that source code. That has not been anything reported on that in a while either, though I think you only get 3DES if I recall correctly.
They mention Debian and 4.7p1 since that is what the researchers targeted. It was not fixed until 5.2. For various reasons Debian will not go past 4.7 for a while yet.
The flaw is in the RFC since 4251 says that the server has to communicate the fact that there was an error. OpenSSH would communicate that as soon as it noticed. By the attacker replaying data slowly it could figure-out out bits in the plaintext. Now OpenSSH waits until it gets a lot of data before it responds. See not every implementation needs to be vulnerable by following the RFC, but they are if they follow it in the naive way.
In fact it could have been much worse. Measures could have been taken to reestablish the connection after the error. In the OpenSSH implementation the connection is dropped on the first such error. But there were (as yet undisclosed) implementation details in OpenSSH that improved the odds of success from the theoretical 2^-18 to 2^-14.
5.1 is vulnerable. If you cannot upgrade just disable all CBC mode ciphers on your server. Some clients will not be able to negotiate a ciphersuite then and the connection will fail for those. If you need CBC for those reasons upgrade or back port.
Basically only CBC is vulnerable, so they prefer others. Also they now read the maximum size before returning an error. There still is a very slight information leak from timing analysis but it would make the chances much much smaller, to the point that it is now an infeasible attack:
http://www.openssh.com/txt/release-5.2
Security:
* This release changes the default cipher order to prefer the AES CTR
modes and the revised "arcfour256" mode to CBC mode ciphers that are
susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".
* This release also adds countermeasures to mitigate CPNI-957037-style
attacks against the SSH protocol's use of CBC-mode ciphers. Upon
detection of an invalid packet length or Message Authentication
Code, ssh/sshd will continue reading up to the maximum supported
packet length rather than immediately terminating the connection.
This eliminates most of the known differences in behaviour that
leaked information about the plaintext of injected data which formed
the basis of this attack. We believe that these attacks are rendered
infeasible by these changes.
And more seriously openssl which led to a lot of unlucky people having generated keys much weaker than they had expected.
Not really, there are not enough sensors to narrow it down enough. A competent tech knows what to do next to diagnose anyway and does not need any AI to help. You also always have to imagine that the sensor is bad as well. In fact that is why there are often more than one of each sensor.
I'm in sort of a similar predicament here at work. A few years ago I did the software for some hardware replacement. Think industrial controls. A year later they wanted diagnostics like that. The old system was like that, since the field bus was so primitive. Basically no communications meant go replace the module with a spare. Now things are much more complicated. There is a remote box, then there is a fiber or serial cable to a PMC (like small PCI) card. That then is on a VME processor board with an ethernet jack. That goes into a switch, and a whole mess after that. There is another computer in the control system that is a consolidator/gateway. Then there is the console that gets run over X11 (through an ssh gateway) on some PC. You can see how when I get an error like request timed-out it is now basically impossible to say where the problem occurred (it is most likely not the hardware).
But they wanted something, so I made a procedure. It is essentially this:
Do a remote reset over the network of the remote unit.
Do a remote reset over the network of the VME crate.
Go out to the remote unit with a kit (I put it together).
Press the reset button.
Put on the dongle, press the reset button. (The dongle being present clears the NVRAM on reset, there is a lot more you can do over the serial interface though.)
Go to the VME crate, cycle power.
Replace the fiber or serial cable (in the kit).
Replace the remote unit (in the kit).
Replace the PMC (in the kit).
Call the tech on the call-in list (could be me).
Whatever you replaced bring back, a tech will look at it then during normal work hours.
That works pretty well in practice actually.
I've done Dodge, Volvo, Mazda, Ford, and Chevy. When I needed to deal with VW I had to use a better reader that my tech friend had access to. It is neat the stuff that you can get off of the VAG on a notebook. There are all these curves plus it is a lot like a PLC and for various modules you can set parameters that are essentially 16-bit words exported in the address space of every module. Still it only tells you such and such a sensor detected this and you need to use instinct, gut, and experience to figure-out why.
Thank you for the reply.
I'm lucky. I had a very frugal father. He bought only GM cars when I was a kid in the US. Mostly SBC but there was an Olds 307 and a Buick 350 (also a Ford Grand Torino, but it was such a mess he gave it to my uncle who sold it quickly). In the '80s we had used cars from the '70s to give an idea. I was always curious and around him (even when very young and he worked on a pair of Skodas in Austria and a Ford Tractor in Poland). In the second grade I helped him rebuild a small Briggs and Stratton (I was the gopher, go-fer that wrench, etc). Then in the fifth grade I rebuilt the same small engine over two evenings with him looking over my shoulder from time to time. Then I helped him and my uncle more and more with the cars. My mother worked for an OEM soldering electronics and building wiring harnesses. My aunt and uncle worked as auto mechanics and later my uncle started a parts store. My aunt would rebuild alternators, starters, transmissions, etc for him. My father was an engineer but in aerospace/defense. By the time I had my first beater I had a lot of help and enough experience to get into trouble. I loved it. In 2004 I bought a new car for the first time for my wife. A few years later I sold the Mazda and bought a new car of my own. I've done a lot less work since then. I really miss it, though free weekends and evenings are nice and I know some former neighbors very much did not like my working on the Mazda and Volvo (the last of my project/daily driver cars).
Sometimes you get different code sets depending on the region your car is initially sold in (different code in the firmware that runs different monitors) or where the ABS module was from Bosche or another later cheaper OEM.
The other thing is that a local mechanic can do the work and submit it as warranty work for almost all cars. They need to do some paper work, but they generally like it since the manufacturer lets them say that it even took more than the book time that dealer service gets to quote. This is the case precisely since there are some cases where a dealer service center is just too far away. Sometimes oyu have to pay for a really expensive tow though.
Lots of cars were like this. I had a Mazda with with a few terminals. There was a screw to ground a pin to reset the codes. Another terminal you could put an multimeter prong in when you grounded another pin with the same screw. Then you watched the needle for the codes.
I had a Volvo that had a little box with a LED and a couple of buttons, very simple. These were early OBD-II cars.
Oh you lack experience, it could be lots of other things. Semi often I have seen a gummed-up PCV valve. Was that the cause though? Nope how did it get that way? Why bound or worn piston rings. That let too much blow back into the crank case. The oils gummed-up the valve, then the gas vapors go right back in the cylinder constantly, making it rich.
What evidence did I have other than a small LCD screen for this back in the day? The valves made a characteristic sound from the carbon deposits and the oil looked black soon after being changed. Lots of things can cause those, but it is just another piece of the puzzle.
Reseat the valve, replace the PCV valve and the piston rings, then things were great. (Well you had to adjust the carb(s) too of course.)
OBD-II (the UART mentioned in the article) does not really tell you what is wrong with your car. It gives you another clue. Experience, know-how, tools, other clues, and a process of elimination tells you what is wrong with your car. OBD-II tells you that something was detected like a knock, misfire, oxygen rich, emissions leak, etc. Now a mechanic has to hunt down the cause and fix that. I just wanted to make that clear. It is like looking at iostat not dtrace.
It will be nice to get the codes, but most of them are pretty much known by now. Some ranges are pretty defacto standard too. It's annoying though that the codes can be different on the same model car sold in CA vs IL though. That can trip you up when you have a code list that does not include the correct region.
Cisco got into trouble about this when they bought linksys which made some hardware that used GPL stuff. They used linux, uLibC, BusyBox, Zebra, and other projects. Then they were contacted and they released source that was not really the source used. They then basically corrected that. Then this situation kept repeating a few times.
If you were worried about security, there was a bug in an web page used for ping that let you run arbitrary commands as root on a whole bunch of hardware. This was figured-out before any source was ever released. The thiobor line of firmware for a long time was just a improved version of what linksys provided. When cisco bought linksys they quickly made a vxworks based router/ap to not have to deal with the OSS stuff. There are no secrets in this stuff that has been released like you worry about. It is not IOS.
I bought a student version of Borland C/C++ back in the day. It cost $400. One stipulation in the license was that I could only use the tools for educational purposes. Various things were explicitly called-out as prohibited. One was selling software that I built with the tools. I also could only demo my software under certain conditions. The cheapest version of Borland without such restrictions was $1000 at the time. This was the one without much support, no DB stuff (pre dBase, was that Fox), no extender (was it pharlap that Borland bundled back then), no Pascal (pre Delphi), etc. Some things are nicer in this day than back then.
I outlined three big deals here:
http://slashdot.org/comments.pl?sid=1238767&cid=28032569
Two are local to the same machine for admin users, one is to other machines on the network that have been previously logged in to in various ways for any kind of user.
It is very easy to think of trouble.
One problem is that the majority of OS X users run as an admin user. Look at the permissions on say /Applications, trivial to drop a trojan there that some one else later runs. Also I see that the permissions are also screwed-up on many machines. I just took a look at /Applications/Safari.app/Contents/MacOS/Safari on one machine and I see that any admin user can rewrite it to anything they like. In fact it may be typical for Applications to be like that for all I know.
Another problem is that Apple has adopted kerberos for use like people would use ssh-agent on other unix-alikes so any networked machine they had recently been on the code an get to without a new password prompt. The output of klist also gives oyu hints of what hosts to try. This makes it easier to spread from one machine to the next.
All this with-out a local priv escalation.
Does anyone know if the OpenJDK6 now compiles on ppc macs? Would I be able to compile the macport version?
In college one of my computers was a notebook that had Cirrus Logic graphics with 1MB of VRAM. Unfortunately the DACs were slow so the refresh at 1024x768 was very slow (intended for interlaced mode). I ran Linux with Xfree86 in a peculiar resolution that I think was 1120x704 (yes it was not square on my monitor, your brain gets used to it though) because the horizontal retraces took a lot of valuable time and I was able to eek about a 10% higher refresh rate (almost 50Hz, okay with mostly black backgrounds) that way. That left me about 256K of extra VRAM. I used a portion of that to make the screen a bit virtually taller and wider for my icons in fvwm (xterms on the right going down, some special apps in a box on the right at the bottom, and everything else along the bottom) plus everything else was used by the Xserver to cache frequently used pixmaps. So I was using all of that 1MB. I tried very hard to get the LCD and external monitor to work in non mirrored mode, but was never able to tweak the X driver for that (it worked in Windows, that would have been another way to use all the VRAM), the CL documentation was full of errors. I did get 16-bit (really 15-bit, one bit was an 'alpha bit' used in accelerated bitblt routines provided by the chip) to work in SVGAlib though which was not even in the Windows driver. It was very incompatible with another person's card though so it never got accepted.
Just reminiscing...
Did you have something like a 80-100MHz 386SX because "7th Guest" ran just barely on my 33MHz 486DX with very expensive 128K of cache on the motherboard (that was very peculiar back then). I also had a 1MB Trident 16-bit ISA SVGA card, that bus really hampered video performance. That was good enough for 256 colors at 1024x768 and the clock was really slow so the refresh was very low. To really run that game you needed at least a 50MHz 486DX (assuming the typical no extra cache) and a VLB video card (yes they did make VLB on 486 as well for a while).
Back then some cards could do 24-bit at 640x480 and 15-bit/16-bit at 800x600 and 2MB cards were just around the corner. Also the address space of ISA is only 16MB, it would really be hard to use a 128MB ISA card. In fact towards the end every program I had used my Trident card with a 64K window into the framebuffer since I eventually had 20MB of RAM and the memory controller could not deal with those bus addresses conflicting.
A lot of PID loops do this sort of average in the I term. Choose your constants right the stale data becomes meaningless soon. No it is not an average but is commonly called that.
What about the large portion of the population that have 'minor constriction' indications if they take a spirometer test, does the breathalyser flag the reading as potentially invalid? About one in five adults have a minor constriction.
Look-up a bunch of cheap hosting providers. How many have postgres? How many have mysql? See why you might choose mysql over postgres (or db2 or sysbase or oracle) for non-technical reasons?