As you can see in the relevant bugtraq post, this was made public about 4 days ago.
The fix is already in the archives (a check that ensures that 'RELATED' connection have the same source address as the initiating original connection), and works fine.
I have had a yopy since just a bit after the development kit came out (serial number 80 or something!), and it rules. One of the big disadvantages was the W Window system - the built-in applications were quite useful, but extendability was low. After the X patches came out I installed X and icewm on it, and it's working great now.
In my opinion there are a couple of disadvantages of the yopy:
no PCMCIA - compactflash is 'nice', but not great. PCMCIA is way cheaper, and allows for more (supported) hardware.
not enough flash - my filesystem is _constantly_ full.
no ethernet - i mount some of my development harddisk space over a serial ppp link on the yopy - slowwwww.
The rest of the thing is great - i hope they'll have the thing on the market soon, and cheaper than the development version...
By the way - for more information about the yopy/development for the yopy check my site, i'm hosting the unofficial yopy faq there as well.
The main thing i thought (after reading the article) was that it's mostly
right, as far as i know.
The package-signing thing has been bothering me as well.
But.
The example of rpm's package-signature checking gives an example of a
better idea, but i don't want to think about what happens when the vendor
key is compromised.
If somebody has the key the rpm's are signed with, he/she can create a very
real false sense of security ('the signature's right, so the package is 100%
certain correct and secure, as well'), by applying the signature to
altered/compromised packages.
The lilo-security thing seems a little farfetched to me as well. I didn't
see a comparison with other distributions, and as far as i know, there are
no other distributions that enforce a lilo-password.
Did he check the packages of wich you mentioned there was a security hole
in them (proftpd, apache) ?
A lot of debian packages (and these as well, afaik), are patched to fix
those holes.
Apart from that, Debian offers (fast) updates to vulnerable packages, in the
form of a security.debian.org apt-rule, where fixed/patched versions are
available.
From the article:
>This portion could be rather long, so I'll cut the list short. Debian has
>shipped more than a few daemons that have severe security problems, many
>of which were fixed well before Debian 2.2 was released. I find this
>unacceptable, especially in the light that Debian has not released any
>updates for these packages!
I wonder if he actually checked all these 'more than a few daemons'. By my
knowledge there are no publicly known vulnerabilities in Debian.
Some comments on the summary:
>Debian's goal of a bug free-release hasn't been met. But to be fair, it's
>not like any software vendor will ever release bug-free software.
>Debian has done a particularly bad job in my opinion, shipping out-of-date
>software and especially publicly available network daemons that have root
>hacks in them.
There is no such thing as a bug-free release.
Debian has done a pretty good job in keeping their releases (including the
latest one) secure.
There is no software shipped in the last Debian distribution with the
publicly known root hacks mentioned.
>If you do go with Debian, you'll have a lot of manual updating ahead of you
>to bring it up-to-date and secure it. Unfortunately, the argument "
>apt-get, apt-upgrade" won't work, since many of these updates are not
>available as dpkg's yet.
Adding security.debian.org in your apt-rules list works just fine. A lot of
Debian maintainers fix security bugs in their packages, often before they
become publicly known.
An out-of-the-box Debian system will only have the security bugs that have
become publicly known after its release date, and these can be fixed with
the above-mentioned security updates.
>Debian has also ignored a lot of work other vendors have put into making their
>distributions more secure. If you don't learn from the mistakes and
>improvements of others, there is little hope. This is especially frustrat
>ing in light of Debian's effort to secure various parts of the distribution,
>using Exim by default instead of Sendmail.
>Having seen things like that during the install, I had a lot of hope for
>Debian, but my hopes were dashed to pieces upon closer inspection.
Debian is a distribution that _adds_ to the work other vendors do, making
their distributions more secure.
If he actually would would have taken a closer look (wich he obviously
hasn't done), he would've seen there's a lot more work being done on the
security of Debian than there's mentioned.
The article shows some knowledge of security in linux systems, but also a
very badly-informed, no-research, superficial look on Debian security
issues.
It is _not_ illegal to reverse-engineer anything in the netherlands, as long as you only release information about the reverse-engineered product. (Our lawyer checked this extensively)
I work at a company that supports open source software, and development of open source software. We ran into a situation where we needed to have open source drivers, as opposed to the (available) closed source drivers. (for those interested, try searching for 'philips webcam drivers' on linuxtoday or linuxnews or something) Links to the stories can be found here.
Our action was, to get the binary-only drivers, disassemble (reverse-engineer) them, and rewrite them, as open source.
I think the best action in situations such as these, is to try to convince the manufacturer first. Often they don't want to give away specifications, or they don't get the advantages (selling more hardware because of there is support for it in free operating systems). In cases such as those, the only way to get open source drivers is reverse-engineering protocols or binary-only drivers. Reverse-engineering and rewriting the driver can be a lot of work, but hey - it's worth it:) As for the legal implications, we were able to do it legally. In the netherlands (and i know there are other countries with similar laws) it is legal to reverse-engineer a piece of software, and to make the information you get from it public. In our case, releasing a complete open source driver was not possible, so we had to make an information package (wich included a basic driver as a reference). Other people are allowed to re-use this information, and make the real driver.
As far as i'm concerned, there is always a way out, and always a way to get an open source driver for a piece of hardware.
Linking to mp3's is already illegal in the netherlands. One of the users on a box of mine had some links to 'illegal' mp3's, and i got a nice letter from a dutch copyright-enforcement bunch.(find it here)
Funny though, because the copyright enforcers in the netherlands are not government-related. This wouldn't be a problem, but i wonder how they check if the material is illegal; they would have to download and listen to it first.
I like MySQL. It's pretty much the 'standard', amazingly fast, and it has good support among a lot of different platforms (even M$!). There _is_ however a bit of discussion possible about the quality of the mysql source code. I think it will be safe to assume that MySQL is heavily optimized for speedy operation, but in my experience this sometimes has a negative influence on the clearness and security of the source code. I have spent some time looking at the MySQL source code, trying to find vulnerabilities (sue me, i've got weird hobbies), and it isn't a pretty sight (you can see the first part of my results here, if you're interested). Apart from the source code - MySQL has a license that's not entirely clean, as well (it looks free, but it isn't ). Taking a look at postgresql, i see lots of clean code, features, and a better license. I still think that MySQL is a cool database system, but from the source code and licensing scheme, I take the performance panelty, and use postgresql.
I really wonder what OS they're going to run on that.. a Beowulf cluster of that size would be quite cool, actually... I wonder if they would let me run SETI on that one:)
This sounds a _lot_ like the tactics shown by some well-known software manufacturers, at least one springs directly into mind:) Are you sure you didn't write this a couple of ears ago, and it leaked out ? nice piece:)
I won't comment on the quality of the 'maximum linux security' book - but there's one thing to keep in mind: it's off-topic. Securing a system is making it safe, whereas intrusion detection is something totally different: registring security-breach attempts.
I think that's kinda cool:) I mean - i guess there _is_ quite a philosophical point being made in the movie, when you think of it...
I can't wait until 'the matrix 2' rolls out in the cinemas.. I heard that in 'the matrix 2' they find out that the 'real world' outside the matrix is actually a matrix too - i wonder what the effect of _that_ fact in a philosophy class will be.. - total confusion probably.
This sounds like one of the more useful addons for the gameboy:) When i saw the little snap-on camera and printer thing, i couldn't believe my eyes, but this is even funnier:)
Personally, I'd rather listen to my mp3's on the road using my boring, simple rio player.
What's most needed at this time (in my opinion) is an open source ILS server that is compatible with (sorry) Netmeeting. To start pulling more people over to linux, we need to start converting server platforms, allowing clients to use either M$ or linux software. If there's no good free ILS/netmeeting server software available, the server side stays tied to M$/non-free alternatives, wich is not what's wanted.
Firstly - linux is not last anymore;) - probably due to the slashdot effect, lots of people hyped up the linux scores.
Apart from that, the rating system used by deja is not really fair. Using people to rate different os-es results in people rating their os of choice high, and the other ones lower. This results, in turn, in people over-rating and under-rating their own and other operating systems because they can see the results already. A better system would be 'what is your system of choice' and give a couple of os-es to pick from (the slashdot way).
What i would have done. If you find a proftp daemon with the right version, and you _know_ this version is vulnerable on other platforms (in the case of bufferoverflows platforms not 'suffering' with a non-executable stack), the only thing you have to do is incorporate shell code for the 'target' platform into the standard exploit, and probably change some offsets. If you regularly keep track of the (abundant) security mailing lists, you see that there is a _huge_ amount of buffer overrun exploits to be found. Modifying shellcode to work on other hardware platforms is not arcane science; you can find lots of tutorials about it on the web (take mudge's 'smashing the stack for fun and profit' for example). The difficulty in this case is that you need to create carefully crafted directories in the world writable directory, _and_ the buffer overflow is not directly made; a buffer is overrun, and the net result doesn't show until strlen() is called in another function. Hard thing. Still, the core task of porting the exploit to another platform is porting the shellcode.
According to your site, you have developed a quite powerful source code security analysis tool. A while ago, this tool was not distributable, and closed source. Do you plan on releasing Slint and/or other currently closed source L0pht tools in an open source license, or in some other freely distributable binary form ?
It looks very interesting, but it's a Bad Thing that it's closed source:( Let's hope the XFree people learn all kinds of interesting stuff from the non-free server, so we can all enjoy a good opensource licensed OpenGL Xserver:-)
a world writable ftp directory exposes a remote root vulnerability in this version of proftpd. Check your standard script kiddie sites (i.e. rootshell, securityfocus et al.)..
I hadn't even _tried_ that one:) Funny, that even with competitions like this, the easy holes always seem to stay open.. I think it's sort of a bad thing that the linuxppc guys missed it themselves though...
As far as i know, the only way to check for non-cheating binaries is allowing a fixed set of binaries that are known to be non-cheating. This is a Bad Thing (tm) - because who's going to check and verify them ? The binaries would have to fulfill a couple of conditions:
They are known not to cheat
They have a valid checksum
They have been entered into the closed source checking system.
As far as i know, only point 2 is manageable, and not bad for things. How do you know a binary is not cheating ? - somebody would have to do a _really_ thorough source analysis (i.e. diffs), and analyzing diffs is not a fun thing to do. Then there needs to be a trusting party, that allows trustworthy people to enter the trusted checksum into the closed source checking system, wich will be a slow, annoying process that will return on each new binary release. (public key encryption/gpg and stuff might make a difference, but it's _still_ annoying to have to have your source checked (and compiled!) by a trusted party before you can use it on the game servers...)
If anyone has a better idea - i can always miss something...
I think that playing games using cheats is just not fun anymore. I also think that cheating players can be easily identified and booted out by the server administrator; unnoted cheats don't make that much difference, and are not always a Bad Thing.
Using opensource game systems will (as far as i know) always allow cheating, unless there is a _server_ solution that identifies that somebody's cheating - and we will probably not have that until everybody runs around with huge origin2000-ish computers, and the server is 1000fold that.
It doesn't look _that_ nice, but it has some nice options i didn't find in the aibo.. i.e. you can make it do stuff for you, let it change channels and fetch mail and stuff - i think i like it better because it's more of a 'digital servant' kind of thing:) Let's hope this is the first step towards a robot that _really_ can do what you tell it to:)
Firstly because the directX support will allow better emulation of the windows platform for games.
Secondly and more importantly, the argument 'Linux runs your windows apps as well' will help windows-users make the switch to linux easier, and let them get to the linux-only apps step by step.
Slashdot Mirror
As you can see in the relevant bugtraq post, this was made public about 4 days ago.
The fix is already in the archives (a check that ensures that 'RELATED' connection have the same source address as the initiating original connection), and works fine.
One of the big disadvantages was the W Window system - the built-in applications were quite useful, but extendability was low. After the X patches came out I installed X and icewm on it, and it's working great now.
In my opinion there are a couple of disadvantages of the yopy:
no PCMCIA - compactflash is 'nice', but not great. PCMCIA is way cheaper, and allows for more (supported) hardware.
not enough flash - my filesystem is _constantly_ full.
no ethernet - i mount some of my development harddisk space over a serial ppp link on the yopy - slowwwww.
The rest of the thing is great - i hope they'll have the thing on the market soon, and cheaper than the development version...
By the way - for more information about the yopy/development for the yopy check my site, i'm hosting the unofficial yopy faq there as well.
The main thing i thought (after reading the article) was that it's mostly right, as far as i know.
The package-signing thing has been bothering me as well.
But.
The example of rpm's package-signature checking gives an example of a better idea, but i don't want to think about what happens when the vendor key is compromised. If somebody has the key the rpm's are signed with, he/she can create a very real false sense of security ('the signature's right, so the package is 100% certain correct and secure, as well'), by applying the signature to altered/compromised packages.
The lilo-security thing seems a little farfetched to me as well. I didn't see a comparison with other distributions, and as far as i know, there are no other distributions that enforce a lilo-password.
Did he check the packages of wich you mentioned there was a security hole in them (proftpd, apache) ? A lot of debian packages (and these as well, afaik), are patched to fix those holes. Apart from that, Debian offers (fast) updates to vulnerable packages, in the form of a security.debian.org apt-rule, where fixed/patched versions are available.
From the article: >This portion could be rather long, so I'll cut the list short. Debian has
>shipped more than a few daemons that have severe security problems, many
>of which were fixed well before Debian 2.2 was released. I find this
>unacceptable, especially in the light that Debian has not released any
>updates for these packages!
I wonder if he actually checked all these 'more than a few daemons'. By my knowledge there are no publicly known vulnerabilities in Debian.
Some comments on the summary:
>Debian's goal of a bug free-release hasn't been met. But to be fair, it's
>not like any software vendor will ever release bug-free software.
>Debian has done a particularly bad job in my opinion, shipping out-of-date
>software and especially publicly available network daemons that have root
>hacks in them.
There is no such thing as a bug-free release. Debian has done a pretty good job in keeping their releases (including the latest one) secure. There is no software shipped in the last Debian distribution with the publicly known root hacks mentioned.
>If you do go with Debian, you'll have a lot of manual updating ahead of you
>to bring it up-to-date and secure it. Unfortunately, the argument "
>apt-get, apt-upgrade" won't work, since many of these updates are not
>available as dpkg's yet.
Adding security.debian.org in your apt-rules list works just fine. A lot of Debian maintainers fix security bugs in their packages, often before they become publicly known. An out-of-the-box Debian system will only have the security bugs that have become publicly known after its release date, and these can be fixed with the above-mentioned security updates.
>Debian has also ignored a lot of work other vendors have put into making their
>distributions more secure. If you don't learn from the mistakes and
>improvements of others, there is little hope. This is especially frustrat
>ing in light of Debian's effort to secure various parts of the distribution,
>using Exim by default instead of Sendmail.
>Having seen things like that during the install, I had a lot of hope for
>Debian, but my hopes were dashed to pieces upon closer inspection.
Debian is a distribution that _adds_ to the work other vendors do, making their distributions more secure. If he actually would would have taken a closer look (wich he obviously hasn't done), he would've seen there's a lot more work being done on the security of Debian than there's mentioned. The article shows some knowledge of security in linux systems, but also a very badly-informed, no-research, superficial look on Debian security issues.
It is _not_ illegal to reverse-engineer anything in the netherlands, as long as you only release information about the reverse-engineered product.
(Our lawyer checked this extensively)
This seems very familiar.
:)
I work at a company that supports open source software, and development of open source software.
We ran into a situation where we needed to have open source drivers, as opposed to the (available) closed source drivers.
(for those interested, try searching for 'philips webcam drivers' on linuxtoday or linuxnews or something)
Links to the stories can be found here.
Our action was, to get the binary-only drivers, disassemble (reverse-engineer) them, and rewrite them, as open source.
I think the best action in situations such as these, is to try to convince the manufacturer first. Often they don't want to give away specifications, or they don't get the advantages (selling more hardware because of there is support for it in free operating systems).
In cases such as those, the only way to get open source drivers is reverse-engineering protocols or binary-only drivers.
Reverse-engineering and rewriting the driver can be a lot of work, but hey - it's worth it
As for the legal implications, we were able to do it legally. In the netherlands (and i know there are other countries with similar laws) it is legal to reverse-engineer a piece of software, and to make the information you get from it public.
In our case, releasing a complete open source driver was not possible, so we had to make an information package (wich included a basic driver as a reference).
Other people are allowed to re-use this information, and make the real driver.
As far as i'm concerned, there is always a way out, and always a way to get an open source driver for a piece of hardware.
Linking to mp3's is already illegal in the netherlands.
One of the users on a box of mine had some links to 'illegal' mp3's, and i got a nice letter from a dutch copyright-enforcement bunch.(find it here)
Funny though, because the copyright enforcers in the netherlands are not government-related.
This wouldn't be a problem, but i wonder how they check if the material is illegal; they would have to download and listen to it first.
I like MySQL. It's pretty much the 'standard', amazingly fast, and it has good support among a lot of different platforms (even M$!).
There _is_ however a bit of discussion possible about the quality of the mysql source code.
I think it will be safe to assume that MySQL is heavily optimized for speedy operation, but in my experience this sometimes has a negative influence on the clearness and security of the source code.
I have spent some time looking at the MySQL source code, trying to find vulnerabilities (sue me, i've got weird hobbies), and it isn't a pretty sight (you can see the first part of my results here, if you're interested).
Apart from the source code - MySQL has a license that's not entirely clean, as well (it looks free, but it isn't ).
Taking a look at postgresql, i see lots of clean code, features, and a better license.
I still think that MySQL is a cool database system, but from the source code and licensing scheme, I take the performance panelty, and use postgresql.
I really wonder what OS they're going to run on that.. a Beowulf cluster of that size would be quite cool, actually... :)
I wonder if they would let me run SETI on that one
This sounds a _lot_ like the tactics shown by some well-known software manufacturers, at least one springs directly into mind :) :)
Are you sure you didn't write this a couple of ears ago, and it leaked out ?
nice piece
I won't comment on the quality of the 'maximum linux security' book - but there's one thing to keep in mind: it's off-topic.
Securing a system is making it safe, whereas intrusion detection is something totally different: registring security-breach attempts.
I think that's kinda cool :)
.. - total confusion probably.
I mean - i guess there _is_ quite a philosophical point being made in the movie, when you think of it...
I can't wait until 'the matrix 2' rolls out in the cinemas..
I heard that in 'the matrix 2' they find out that the 'real world' outside the matrix is actually a matrix too - i wonder what the effect of _that_ fact in a philosophy class will be
This sounds like one of the more useful addons for the gameboy :) :)
When i saw the little snap-on camera and printer thing, i couldn't believe my eyes, but this is even funnier
Personally, I'd rather listen to my mp3's on the road using my boring, simple rio player.
What's most needed at this time (in my opinion) is an open source ILS server that is compatible with (sorry) Netmeeting.
To start pulling more people over to linux, we need to start converting server platforms, allowing clients to use either M$ or linux software.
If there's no good free ILS/netmeeting server software available, the server side stays tied to M$/non-free alternatives, wich is not what's wanted.
Firstly - linux is not last anymore ;) - probably due to the slashdot effect, lots of people hyped up the linux scores.
Apart from that, the rating system used by deja is not really fair.
Using people to rate different os-es results in people rating their os of choice high, and the other ones lower.
This results, in turn, in people over-rating and under-rating their own and other operating systems because they can see the results already.
A better system would be 'what is your system of choice' and give a couple of os-es to pick from (the slashdot way).
It's a good thing the pentium III finally came out in fpga form factor - slot1 boards are simply too expensive, and not handy enough.
What i would have done.
If you find a proftp daemon with the right version, and you _know_ this version is vulnerable on other platforms (in the case of bufferoverflows platforms not 'suffering' with a non-executable stack), the only thing you have to do is incorporate shell code for the 'target' platform into the standard exploit, and probably change some offsets.
If you regularly keep track of the (abundant) security mailing lists, you see that there is a _huge_ amount of buffer overrun exploits to be found.
Modifying shellcode to work on other hardware platforms is not arcane science; you can find lots of tutorials about it on the web (take mudge's 'smashing the stack for fun and profit' for example).
The difficulty in this case is that you need to create carefully crafted directories in the world writable directory, _and_ the buffer overflow is not directly made; a buffer is overrun, and the net result doesn't show until strlen() is called in another function. Hard thing.
Still, the core task of porting the exploit to another platform is porting the shellcode.
According to your site, you have developed a quite powerful source code security analysis tool.
A while ago, this tool was not distributable, and closed source.
Do you plan on releasing Slint and/or other currently closed source L0pht tools in an open source license, or in some other freely distributable binary form ?
It looks very interesting, but it's a Bad Thing that it's closed source :( :-)
Let's hope the XFree people learn all kinds of interesting stuff from the non-free server, so we can all enjoy a good opensource licensed OpenGL Xserver
Emphyrio
a world writable ftp directory exposes a remote root vulnerability in this version of proftpd.
Check your standard script kiddie sites (i.e. rootshell, securityfocus et al.)..
Emphyrio
I hadn't even _tried_ that one :)
Funny, that even with competitions like this, the easy holes always seem to stay open..
I think it's sort of a bad thing that the linuxppc guys missed it themselves though...
Emphyrio
This is a Bad Thing (tm) - because who's going to check and verify them ?
The binaries would have to fulfill a couple of conditions:
- They are known not to cheat
- They have a valid checksum
- They have been entered into the closed source checking system.
As far as i know, only point 2 is manageable, and not bad for things.How do you know a binary is not cheating ? - somebody would have to do a _really_ thorough source analysis (i.e. diffs), and analyzing diffs is not a fun thing to do.
Then there needs to be a trusting party, that allows trustworthy people to enter the trusted checksum into the closed source checking system, wich will be a slow, annoying process that will return on each new binary release. (public key encryption/gpg and stuff might make a difference, but it's _still_ annoying to have to have your source checked (and compiled!) by a trusted party before you can use it on the game servers...)
If anyone has a better idea - i can always miss something...
I think that playing games using cheats is just not fun anymore. I also think that cheating players can be easily identified and booted out by the server administrator; unnoted cheats don't make that much difference, and are not always a Bad Thing.
Using opensource game systems will (as far as i know) always allow cheating, unless there is a _server_ solution that identifies that somebody's cheating - and we will probably not have that until everybody runs around with huge origin2000-ish computers, and the server is 1000fold that.
Just my $.02..
Emphyrio
It doesn't look _that_ nice, but it has some nice options i didn't find in the aibo.. :) :)
i.e. you can make it do stuff for you, let it change channels and fetch mail and stuff - i think i like it better because it's more of a 'digital servant' kind of thing
Let's hope this is the first step towards a robot that _really_ can do what you tell it to
This is good.
Firstly because the directX support will allow better emulation of the windows platform for games.
Secondly and more importantly, the argument 'Linux runs your windows apps as well' will help windows-users make the switch to linux easier, and let them get to the linux-only apps step by step.