'Named pipes' on Win32 and 'pipes' on POSIX do not have much in common, except the name and the fact that you can send data over it. Win32 pipes are more similar to UNIX domain sockets,
and while GNU/Linux might still be faster even if UNIX domain sockets are used, it wouldn't be by that much.
It would have been interesting to see how real POSIX pipes behave on Windows (for example, in the POSIX subsystem or on Interix, or even on Cygwin).
Finally, as far as I know, the Win32 API provides other IPC mechanisms, and for transferring large amounts of data, other interfaces are usually used by Win32 programs. That's why the throughput of pipes is not so important on Win32 systems, and performance has not been optimized.
Exploits that lead to user-access is normally less important than exploits that lead to root-access.
Unfortunately, this is not true in practice.
It is extremely difficult to maintain local security on UNIX systems if you and your users are using quite a few tools. For example, GNU Emacs 20 still has temporary file races (really old advisory), and a lot of your favorite tools, too. Such problems disappear only very, very slowly.
Of course, there seems to be a way out of this dilemma: don't install anything on your server except the server software itself. Put each service (HTTP, SMTP, NNTP) on separate machines, and interactive users onto another. Unfortunately, after you've done this, you are facing a remarkable farm of servers, each requiring maintenance, which is not always acceptable.
As a result, if you have limited capacities (and who doesn't?), you are better off when you focus most of your energy on securing against attacks over the network, as long as you can trust your local users. Relying on the security features of a typical UNIX system to confine a security breach to a certain account is not a good idea, at least at the moment.
Actually Mainframe admins run pretty tight ships as well.
On mainframes (and certain, not very widespread UNIX derivates running on real computers), you can actually reliably separate users from one another,
guaranteeing their privacy
(apart from partitioning the machine to run several kernels in parallel). Implementations
might have a few problems, too, but at least the designers have thought about some important issues.
Local security on UNIX is still pretty much non-existing, not because of tons of problems with MTAs, MDAs, man implementations, temporary races and so on. These are only symptoms, reflecting the fact that the UNIX people have never considered replacing the simple, sometimes reliable, sometimes extremely complicated to use UID/GID/EUID/EGID etc. concept.
O.K. So some of them (no/weak passwords) are user related, but so many of them are admin related (bind vulnerabilities, IIS RDS vulnerabilities)
Anything related to IIS is user-related, too. Quite a few users install a web server without realizing what they are doing. After all, their hard disks are big, and they have paid for this stuff in some way. And there will always be people who complain that security is too complex for them to deal with and refuse to install patches on their favorite web server (usually IIS), unless they are cut off the net until their machines are fixed.
I have to say, it really is nice to see the NSA contributing to an open source project in such a positive manner.
The NSA (or its director) is claiming copyright for quite a few lines in the Linux kernel (IIRC Don Becker's network drivers are under NSA copyright). This is hardly something new.
I understand that people are a bit carried away by their fear of patents. So far, most submissions only reject the idea of patent-based Web technology, but fail to mention severe defects in the protocol outlined in the draft. This is a bit unfortunate because these concerns will be dealt with at the political level (at which the the decisions has already been made in one direction or the other), and the problems at the technical level remain if the draft is implemented despite the political opposition.
For example, errors in the definition of an Essential Claim leave many, many loopholes. An example: If some patented technology is included in the later stage of a Recommendation, a patent owner can, in full compliance with the W3C procedures, obtain a patent without the need to disclose it. And that's not the only error. Basically, the patent holder decides which patents to reveal and which to hold back, and W3C cannot do anything about it. This makes most of the draft meaningless.
Watcom generates very optimal code for the i386. That's also a very impressive feat.
Is it? Nobody is using i386s nowadays, except for embedded applications. The younger members of the ia32 family require rather different optimizations (even when compared to the Pentium or Pentium Pro, totally different when compared to the i386).
Maybe the Watcom compiler generates really good code for the i386, i486, and Pentium processor (perhaps even for the Pentium Pro/II), but AFAIK it doesn't support SSE2, so performance on the Pentium IV won't be much better than GCC. (If it is, it is certainly not due to heavily target-dependent optimizations on Watcoms part.)
The local university over here received complaints because someone was hosting a porn site under a domain name which was confusingly similar to the official one. In such cases, the easiest approach is to acquire the domain name, shutting down the porn site itself is much too complicated. Similar problems occur if some student organization or political party holds critical (i.e. very similar or officially looking) domain names. I can imagine quite a number of domain names pileing up in the course of time.
However, the problem is less drastic over here in Germany because most university DNS entries usually have a UNI- prefix in the second to last component. Anyone registring such a domain who does not represent a university should know that he is heading for trouble, and it is rather unlikely that random collisions occur.
You can get bit-for-bit copies from the digital output of your CD player. For debugging a sound card driver, I once recorded some data from a rather dated Kenwood CD player using its digital output, and compared it to the data ripped by a Plextor CD-ROM drivers. Guess what: after synchronizing these data streams, they were identical. (And that despite of the terrible digital jitter introduced by this old CD player!)
Of course, there are problems: If your sound card cannot sync to the external clock provided by the CD player on the signal, some resampling occurs from time to time. The situation gets worse with those popular sound cards based on the AC97 standard: this standard mandates a fixed internal sampling frequency of 48 kHz, so resampling is always required when recording from a CD. Sometimes, this resampling is implemented so poorly that using the analog inputs of the sound card gives better results...
In addition, even if you use a Linux-based GNU system, you have a broad range of software to choose from to implement your services. There are multiple web servers, FTP servers, MTAs, different SSH implementations, and so on. Of course, this makes keeping track of vulnerabilities a nightmare (Debian is currently looking for someone to do this job, BTW), but if a single vulnerability is identified, it won't affect all of your systems. (In addition, there's a trend towards disabling unnecessary services by default, something which I can't see on the Windows front.)
Fear of monoculture has prevented us from agressively promoting the use of OpenSSH on all our UNIX boxes (we have a couple of thousands of them). Given the code quality of OpenSSH (which doesn't differ much from other SSH implementations, I think), it is not wise to advocate the use of free software in this case.
From a user's and non-WLAN network administrator's perspective, WLAN is a bit like traditional dial-up lines: non-permanent connections, one user might have several hosts (laptop, iPAQ). So you definitely want user-based authentication (perhaps even according to your already existing dial-up user database). As far as I know, all the WLAN security stuff is targeted to host-based security without proper key management protocols, which is not very interesting if you look at this perspective because even if it does provide some security, it is not using a practical scheme.
Facing this kind of problems, our local university decided not to use WEP at all from the beginning, but an IPsec derivate (unfortunately with vendor-specific extensions for the user-based authentication).
I didn't want to say something else. IMHO, qmail and sendmail are so different that you can hardly say which one is better in general, only for specific purposes there might be a clear winner. (If your main criterion is flexibility, sendmail clearly wins hands down.) If you think qmail can do the job, go with it, if you need a development environment for email address parsers, use sendmail.
Personally, I use Exim where I can; another large, monolithic piece of software...
sendmail is one big monolithic piece of software, qmail is not, and qmail is much simpler than sendmail, too. sendmail doesn't suddenly become ultra-secure just because you don't run it as root.
Most of the implementors are explicitly not making an assumption that the terminal is a trusted device, and are relying on the USIM to carry trusted information
(such as identity information), and on encrypted network storage to carry certificates etc.
This isn't enough. These implementations assume that the user interface (display, number pad) can be trusted, too. Once the cell phone resembles a general-purpose computer, this is no longer true.
Of course, even today, people ignore such problems, add a tamper-proof device which stores the secret and performs the crypto operations, but continue to use the host computer to view the documents which are to be signed etc. Of course, this approach is not secure. A few German researches have recently broken such a system even though it had been certified to be "secure".
There are numerous initiatives to use cell phones as trusted computing devices: for micro payment (and even paying large sums), for authentication purposes, for tracking disabled people (in conjunction with GPS, for example), for emergency calls. People even think of using them in the context of legally binding digital signatures.
These applications assume that cell phones are reliable devices, which keep secret data secret and operate without hickups until the battery runs out. So far, none of the initiatives has really gained momentum, but will people stop to reconsider what they are doing when cell phones become more and more similar to general-purpose computers, with fully-fleged browsers showing web content on tiny displays, possibly even including a EMCAscript interpreter?
I don't think so, and the results could be devastating.
As far as I remember, this is done by breaking the protocol, relying on the fact that most server implementations cannot handle passwords with embedded NUL characters.
Given the fact that a lot people who still rely exlusively on SSH1 use an unmaintained version (the proprietary version by SSH Communications Security for UNIX-like operating systems), I don't think it's reasonable to expect that this hole gets plugged any time soon. After all, people are still using SSH versions without the CRC compensation attack detector.
Turn on some music, and enter your password to the rhythm of the music, using one hand for the keys and the other for case shifting.
To be honest, the paper doesn't show much evidence that significant information on passwords can be recovered using this sniffing technique. It is most efficient if you have got a detailed typing profile of your victim. The authors claim that this can be obtained in most cases, but I doubt it. Using the profile of another person doesn't seem to give good results (although Table 1 in the paper is pretty confusing).
Given typical typing speeds (hardly less than 100ms per key press) and the round-trip delays usually observed today (in the 50ms range), the Nagle algorithm doesn't have much effect here: when you type the second key, the client has already received the ACK for the packet with the first key press sent earlier, and sending the second key press is not delayed at all.
This is a red herring, sort of. The initial password is transmitted en bloc. Although there are some information leaks, too (mainly the length of the password), this password is not vulnerable against sniffing the session and guessing passwords by measuring intervals between key presses. The passwords entered during an SSH session in the session itself are at risk (for example, if you call sudo, or if you use SSH with password authentication).
Of course, your terminal emulator could offer you a special way to enter a password and send it en bloc later on, to defeat this kind of attack (much like X keyboard locking in xterm)...
Actually, in the meantime, an additional draft has been released, see for example this copy.
However, no technical changes have been made.
Someone generating load for testing?
on
Akira Re-Released
·
· Score: 1
This is the third story in a couple of days with a link to Animefu. Is CmdrTaco in desperate need for some network load for a new web accelerator or load balanncer, or what?
One database for domain names, and one for IP addresses.
While I can understand privacy concerns associated with the domain name database (and concerns of comapanies that they reveal some pieces of their business plans because they have registered some domain name;-), I think it's essential that the IP adress database has full accurate contact information (including phone numbers and email addresses). IP addresses are normally registered by providers, so there are fewer privacy issues involved (read: hardly any, basically it belongs to their job of providing a network connection for their clients).
It would be a real pitty if both databases were treated the same way by some well-meaning politicians. The IP address WHOIS database is a valuable tool in tracking down net abuse, of course. Abolishing it or reducing the provided contact information could have a negative impact on the net as whole.
It seems to me that the initiators of the projects are overly optimistic regarding the availability of electricity. I've heard of some of the troubles of running computers in developping countries: electrical power is only available in the evenings, if at all, and it's not very reliable.
A few additional problems: You have got a hard time to get any supplies (for example, laser printer toner; some university is asking visiting professors to bring some toner with them for their one and only laser printer) and replacements for broken parts, high-tech devices are usually not designed to be repaired, and it's unlikely that they can be repaired in the same country. Furthermore, a lot of developping countries have quite an extreme climate, which doesn't increase the lifetime of electronic equipment either.
No, I don't think game consoles are a silver bullet in the struggle of educating people in the developping countries.
Slashdot Mirror
Finally, as far as I know, the Win32 API provides other IPC mechanisms, and for transferring large amounts of data, other interfaces are usually used by Win32 programs. That's why the throughput of pipes is not so important on Win32 systems, and performance has not been optimized.
It is extremely difficult to maintain local security on UNIX systems if you and your users are using quite a few tools. For example, GNU Emacs 20 still has temporary file races (really old advisory), and a lot of your favorite tools, too. Such problems disappear only very, very slowly.
Of course, there seems to be a way out of this dilemma: don't install anything on your server except the server software itself. Put each service (HTTP, SMTP, NNTP) on separate machines, and interactive users onto another. Unfortunately, after you've done this, you are facing a remarkable farm of servers, each requiring maintenance, which is not always acceptable.
As a result, if you have limited capacities (and who doesn't?), you are better off when you focus most of your energy on securing against attacks over the network, as long as you can trust your local users. Relying on the security features of a typical UNIX system to confine a security breach to a certain account is not a good idea, at least at the moment.
Local security on UNIX is still pretty much non-existing, not because of tons of problems with MTAs, MDAs, man implementations, temporary races and so on. These are only symptoms, reflecting the fact that the UNIX people have never considered replacing the simple, sometimes reliable, sometimes extremely complicated to use UID/GID/EUID/EGID etc. concept.
Copyright 1993 United States Government as represented by the Director, National Security Agency. - Doesn't look like NASA to me.
For example, errors in the definition of an Essential Claim leave many, many loopholes. An example: If some patented technology is included in the later stage of a Recommendation, a patent owner can, in full compliance with the W3C procedures, obtain a patent without the need to disclose it. And that's not the only error. Basically, the patent holder decides which patents to reveal and which to hold back, and W3C cannot do anything about it. This makes most of the draft meaningless.
My submission was wirtten hastily, so it's probably full of typos,strange thoughts and lack of facts, but if you are interested nevertheless, it's available at: http://www.s.netic.de/fw/w3c-patent-policy-2001-09 -30.pdf
Maybe the Watcom compiler generates really good code for the i386, i486, and Pentium processor (perhaps even for the Pentium Pro/II), but AFAIK it doesn't support SSE2, so performance on the Pentium IV won't be much better than GCC. (If it is, it is certainly not due to heavily target-dependent optimizations on Watcoms part.)
The local university over here received complaints because someone was hosting a porn site under a domain name which was confusingly similar to the official one. In such cases, the easiest approach is to acquire the domain name, shutting down the porn site itself is much too complicated. Similar problems occur if some student organization or political party holds critical (i.e. very similar or officially looking) domain names. I can imagine quite a number of domain names pileing up in the course of time.
However, the problem is less drastic over here in Germany because most university DNS entries usually have a UNI- prefix in the second to last component. Anyone registring such a domain who does not represent a university should know that he is heading for trouble, and it is rather unlikely that random collisions occur.
You can get bit-for-bit copies from the digital output of your CD player. For debugging a sound card driver, I once recorded some data from a rather dated Kenwood CD player using its digital output, and compared it to the data ripped by a Plextor CD-ROM drivers. Guess what: after synchronizing these data streams, they were identical. (And that despite of the terrible digital jitter introduced by this old CD player!)
Of course, there are problems: If your sound card cannot sync to the external clock provided by the CD player on the signal, some resampling occurs from time to time. The situation gets worse with those popular sound cards based on the AC97 standard: this standard mandates a fixed internal sampling frequency of 48 kHz, so resampling is always required when recording from a CD. Sometimes, this resampling is implemented so poorly that using the analog inputs of the sound card gives better results...
In addition, even if you use a Linux-based GNU system, you have a broad range of software to choose from to implement your services. There are multiple web servers, FTP servers, MTAs, different SSH implementations, and so on. Of course, this makes keeping track of vulnerabilities a nightmare (Debian is currently looking for someone to do this job, BTW), but if a single vulnerability is identified, it won't affect all of your systems. (In addition, there's a trend towards disabling unnecessary services by default, something which I can't see on the Windows front.)
Fear of monoculture has prevented us from agressively promoting the use of OpenSSH on all our UNIX boxes (we have a couple of thousands of them). Given the code quality of OpenSSH (which doesn't differ much from other SSH implementations, I think), it is not wise to advocate the use of free software in this case.
The FSF gave Cygnus a different license? What are the differences?
From a user's and non-WLAN network administrator's perspective, WLAN is a bit like traditional dial-up lines: non-permanent connections, one user might have several hosts (laptop, iPAQ). So you definitely want user-based authentication (perhaps even according to your already existing dial-up user database). As far as I know, all the WLAN security stuff is targeted to host-based security without proper key management protocols, which is not very interesting if you look at this perspective because even if it does provide some security, it is not using a practical scheme.
Facing this kind of problems, our local university decided not to use WEP at all from the beginning, but an IPsec derivate (unfortunately with vendor-specific extensions for the user-based authentication).
I didn't want to say something else. IMHO, qmail and sendmail are so different that you can hardly say which one is better in general, only for specific purposes there might be a clear winner. (If your main criterion is flexibility, sendmail clearly wins hands down.) If you think qmail can do the job, go with it, if you need a development environment for email address parsers, use sendmail.
Personally, I use Exim where I can; another large, monolithic piece of software...
sendmail is one big monolithic piece of software, qmail is not, and qmail is much simpler than sendmail, too. sendmail doesn't suddenly become ultra-secure just because you don't run it as root.
Of course, even today, people ignore such problems, add a tamper-proof device which stores the secret and performs the crypto operations, but continue to use the host computer to view the documents which are to be signed etc. Of course, this approach is not secure. A few German researches have recently broken such a system even though it had been certified to be "secure".
There are numerous initiatives to use cell phones as trusted computing devices: for micro payment (and even paying large sums), for authentication purposes, for tracking disabled people (in conjunction with GPS, for example), for emergency calls. People even think of using them in the context of legally binding digital signatures.
These applications assume that cell phones are reliable devices, which keep secret data secret and operate without hickups until the battery runs out. So far, none of the initiatives has really gained momentum, but will people stop to reconsider what they are doing when cell phones become more and more similar to general-purpose computers, with fully-fleged browsers showing web content on tiny displays, possibly even including a EMCAscript interpreter?
I don't think so, and the results could be devastating.
As far as I remember, this is done by breaking the protocol, relying on the fact that most server implementations cannot handle passwords with embedded NUL characters.
Given the fact that a lot people who still rely exlusively on SSH1 use an unmaintained version (the proprietary version by SSH Communications Security for UNIX-like operating systems), I don't think it's reasonable to expect that this hole gets plugged any time soon. After all, people are still using SSH versions without the CRC compensation attack detector.
Turn on some music, and enter your password to the rhythm of the music, using one hand for the keys and the other for case shifting.
To be honest, the paper doesn't show much evidence that significant information on passwords can be recovered using this sniffing technique. It is most efficient if you have got a detailed typing profile of your victim. The authors claim that this can be obtained in most cases, but I doubt it. Using the profile of another person doesn't seem to give good results (although Table 1 in the paper is pretty confusing).
Given typical typing speeds (hardly less than 100ms per key press) and the round-trip delays usually observed today (in the 50ms range), the Nagle algorithm doesn't have much effect here: when you type the second key, the client has already received the ACK for the packet with the first key press sent earlier, and sending the second key press is not delayed at all.
This is a red herring, sort of. The initial password is transmitted en bloc. Although there are some information leaks, too (mainly the length of the password), this password is not vulnerable against sniffing the session and guessing passwords by measuring intervals between key presses. The passwords entered during an SSH session in the session itself are at risk (for example, if you call sudo, or if you use SSH with password authentication).
Of course, your terminal emulator could offer you a special way to enter a password and send it en bloc later on, to defeat this kind of attack (much like X keyboard locking in xterm)...
Actually, in the meantime, an additional draft has been released, see for example this copy. However, no technical changes have been made.
This is the third story in a couple of days with a link to Animefu. Is CmdrTaco in desperate need for some network load for a new web accelerator or load balanncer, or what?
One database for domain names, and one for IP addresses.
;-), I think it's essential that the IP adress database has full accurate contact information (including phone numbers and email addresses). IP addresses are normally registered by providers, so there are fewer privacy issues involved (read: hardly any, basically it belongs to their job of providing a network connection for their clients).
While I can understand privacy concerns associated with the domain name database (and concerns of comapanies that they reveal some pieces of their business plans because they have registered some domain name
It would be a real pitty if both databases were treated the same way by some well-meaning politicians. The IP address WHOIS database is a valuable tool in tracking down net abuse, of course. Abolishing it or reducing the provided contact information could have a negative impact on the net as whole.
It seems to me that the initiators of the projects are overly optimistic regarding the availability of electricity. I've heard of some of the troubles of running computers in developping countries: electrical power is only available in the evenings, if at all, and it's not very reliable.
A few additional problems: You have got a hard time to get any supplies (for example, laser printer toner; some university is asking visiting professors to bring some toner with them for their one and only laser printer) and replacements for broken parts, high-tech devices are usually not designed to be repaired, and it's unlikely that they can be repaired in the same country. Furthermore, a lot of developping countries have quite an extreme climate, which doesn't increase the lifetime of electronic equipment either.
No, I don't think game consoles are a silver bullet in the struggle of educating people in the developping countries.