The reason it should be done in the file transfer utility is simple: by doing it there, you can write a utility for every system you want to communicate, and they will all be able to transfer files between eachother. When you wanted to do it in "a little utility" you would have to write conversions for every kind of peer system into each of the utilities for all your systems, and when a new member joins the club you would have to update all the little utilties to support the new format.
Of course, what was dumb in FTP was the decision to let it use a conversion mode by default. It should have defaulted to "binary" and offer the option for conversions when the user specified them.
There is a similar pest from a virus scanner identifying as ClamAV 0.92.1 It retrieves URLs from our website but it does not include a Host: header with the requests it makes. Of course this makes it fail on websites that use shared hosting on a single IP address.
We know how easy it is to stop botnet spam. The problem is that the party that would have to implement the "solution" is not interested in solving the "problem", and neither do they want to be bothered with users who claim that they cannot mail because of something that has changed.
It always amazes me that botnet spam is so easy to identify and filter at the SMTP level. The programmers that create those trojans and stealthy bots should be quite capable, yet the spamming payloads they (or others?) write to run on the botnets are lousy. It seems like it is too much effort to read RFC-2821 and come up with a spambot that at least talks the SMTP protocol without stupid errors, and on the next level they are not very cleverly written either. (e.g. most botnet spam is still blocked by simple greylisting, because the sender address is apparently generated randomly for every connection attempt)
When I started using Linux, the alternatives were Windows 3.11 and OS/2. That was in december 1992. Windows 95 wasn't officially released until august 1995, nearly 3 years later.
In those days, Linux was already running X. I had a 486 with 16MB RAM and a graphic card with 1024x768 at 8 bits/pixel, but I remember that this system was performance-wise very competitive with the X terminals and VAX/VMS system at work. It was actually quite amazing what had been accomplished with Linux in the few months since its creation (both in kernel functionality and getting existing applications compiled and working).
I work as normal user on XP all day, and so do all our users. Only incompetently managed XP systems provide "a very bad user experience" in that case. Most admins are not interested in finding out how to manage their systems, they prefer quick-and-dirty methods even when it hurts security. When they have tried to install Vista the first thing they are looking up on internet is how to get rid of those "allow or deny" popups:-( With a little more study of the matter they would be able to get their systems secured against exploits like this.
The flaw is causing drive-by malware downloads when an IE user simply browsers to a maliciously rigged Web page
Of course this flaw only affects badly managed systems where the user is browsing the Internet while logged on as an Adminstrator. Microsoft is trying to discourage this but the users are too stupid to realize what they are doing wrong, and keep adding themselves to the Administrators group and keep trying to get rid of "annoying" popups that tell them they need to supply their password before the system will install software.
It would be sufficient when your workstations were setup a bit more securely, and you would not be working as an Administrator or Power User all day. When using a Windows system as a normal user, those exploits do not stand a chance. That would be similar to using Linux as a normal user, not root.
Of course far too many wannabe-windows-admins have yelled "cannot do that, need to be admin to run many programs" because they found that in 2000 and never checked again.
That's why I mentioned only major sites. Look at what is having say 50kW-up of EIRP. Of course we had a couple of filler sites too, but fewer than in a hilly country.
But this should not hinder a digital conversion, it should HELP do do it. In analog TV, you need a single path between your antenna and the site. And you need a unique channel for each of those paths. That is what requires the tedious planning and the many sites.
With digital TV (at least with DVB-T and COFDM as used in Europe) it all is different. You can just flood the country with small transmitters operating in cities and townships, all on the same channel. Those transmitters will not be interfering with another, but they will help eachother to provide every viewer with a signal.
So what can be done is to first convert all major sites to digital as quickly as possible (due to manpower constraints), and then follow up with the minor sites that you still need, at leisure rate. Will be fewer than with analog, but local terrain situations will likely require filler sites.
In fact we now have two differently structured DVB-T networks operating. There is the broadcasting of public TV from the original locations of the analog network (tweaked a bit), i.e. tall towers and lots of power from relatively few locations. Alongside that there is a commercial (encrypted) network providing commercial stations as a pay-service. They use smaller sites at much lower locations, more like cell towers. It is intended for reception using indoor antennas. It existed before the analog switchoff. I think the UK is not that different in this respect.
The story was about the UK. In Europe, we did not use component video in the past but almost every TV produced in the last two decades has an RGB input. RGB is functionally equivalent to component. A Digital receiver usually outputs RGB and composite, which is connected to the TV via a SCART connector that combines composite video, audio and almost always RGB video in a single convenient connection.
The presence of an RGB input is so common because RGB is used for the "Teletext" feature available in almost every TV set, and the video multiplexer used to switch/combine the normal video and teletext signals operates at RGB signals and provides an extra RGB input for external signals.
(component video now appears on newer sets, but more because of compatability with equipment used in the USA than for real need)
It could be that our network was better maintained, better documented etc. We have had rules and regulations for a long time, that disallow the commercial operation of can-and-string cable networks. So our cable networks probably tend to be at a higher level. (for example, cable networks don't get their signals by receiving the public broadcasting network so they were unaffected by this switch)
But in general, it can be said that a conversion like this can be done two ways: by endless debating about a transition period and then taking years, or by applying some pressure and be done with it.
Compared to the UK? I don't think so... We had about 10 major transmitter sites each with 3 analog transmitters that were converted to a single digital multiplex overnight. Later, more work has been done line converting from horizontal to vertical antenna polarization. But that is not really related to the actual conversion, but to the change to a more dense network with capability for indoor reception.
There is a big gap between doing everything on a single day, and taking 5 years to do it. That is not only explained by scale. Maybe there is the assumption that people need more time to prepare. Get digital equipment, install it. But spreading it over a 5 year period certainly will not help. Nobody is going to prepare for something that will happen in 2011 or 2012 in their region. All the preparation will be done in the month before the actual switchover in each area.
Analog signals are expected to have been switched off over the whole of the UK by 2012.
Why so slowly? Over here (Netherlands), analog signals have all been switched off in a single night last year, with the final decision having been made only a couple of months earlier. It was a simple matter of "what does it cost to keep the old system running, per viewer, and what is the cost for conversion to digital". The fact that operating a digital TV transmitter wastes less energy might have weighed in too.
But that would leak pretty quickly, wouldn't it? Just register a new domain, tell Google to spider it, and watch the logs for a while. At first there will only be visits from Google. As time passes it will become more difficult, but you just register another domain.
When being an NTP server you want the clock to be as accurate as possible. The server is often locked to other servers and/or to local radio clock receivers. In a physical machine, there is an accurate hardware timer that is used as the incrementing clock (at micro- or nanosecond rate) and which is frequency locked to the references. Such hardware does not really exist in the virtual machine, it is emulated, and this emulation is not very good even when you sync to the host. It is good enough for "wristwatch time" in your virtual machine, but in an NTP server you expect accuracy to the order of milliseconds when externally synced, or microseconds when synced to local radio receivers. VMware simply is not up to that job.
Although I think ntpd does not have a bad security record (compared to other network services with a long history), I think a better approach to improved security would be to focus on the server code instead of running it in a virtual machine. BTW, the current version already runs in a chroot environment and as a non-root user in modern Linux distributions.
NTP servers are written around precise clocks and with minumum processing latency in mind. An NTP server running on a Windows platform already is significantly worse than one on Unix/Linux, and I think that should not be further degraded by running it in a virtual machine. Remember you want to put the current local time down to nanoseconds in the reply packet. Your underlying platform should be capable of providing that time, and the processing code should not take so long that the time value is completely meaningless.
When you don't trust the program and don't want to put up a dedicated machine with no other critical stuff on it, then it is better to just forget about it.
It has been said many times that it would probably be a good idea to have a computer usage license similar to a driving license. One that requires you to learn basic principles of secure computer use, and that can be withdrawn when excessive neglect leads to insecure situations and/or damages, just like is the case for a driving license. The reason this is not yet in effect, is that driving a car is believed to be able to cause lethal injury, while using a computer isn't. But that is only for now. When a large botnet is being used to attack certain internet sites and causes real damage and maybe death (like a terrorist attack), the situation could change.
I think it is quite scary that the current botnets are tolerated and mostly only their current effects (like SPAM) are combated. It would be much better when major ISPs would take strict measures against anyone found with a bot installed. It is quite easy to assemble lists of IP addresses of infected computers (many of those exist) but nobody does anything about it. Until it is too late and we come under a massive attack not so easily defeated as botnet SPAM, then we will hear that something should have been done.
The problem with Windows (recent versions) insecurity lies mainly in the user instead of the OS. The basic design is quite good, but the average user spends his days working as an admin so all of the protection is effectively disabled. It would be the same when all Linux users were working as root.
Usually a Linux installation procedure tries to convince you that you need a root acccount and a working user account, and often warnings are displayed when you try to use the GUI as root. Similar things were tried with XP SP2 and more in Vista, but the users view it as a nuisance and there is a big demand for "solutions" to disable those popups that ask you to enter a password to do something stupid.
Probably when everyone switched to Linux, the same situation would arise, and it would not take long before similar botnets appeared. Users are not interested in security. They don't see the need, and they hate the extra effort required.
No. A TCP connection does not put load on routers. The reason is that to block a packet you need a device that passes-through packets and could get overwhelmed or be broken, while with the RST method you just need to examine pass-by traffic and send an occasional RST. When your device gets overloaded, it will just miss part of the traffic but the traffic itself will not be hindered.
This will not accomplish much. For one, in Linux the process priority us dynamically adjusted. So a program that hogs the CPU will automatically decrease in priority so that it gets all CPU time remaining after other processes that use little CPU have got their share. It will not really starve lower-priority processes, as happens on a completely priority determined scheduler with static priorities (found in realtime kernels, in Windows NT, etc).
But, another issue is that a process that makes the system slow by allocating lots of memory and causing lots of paging to disk (as described here) is not a CPU hog and will thus not be controlled by the process priority. Even at a very low priority, such tasks can still slowdown the system. You need tuning of the system parameters (via/proc or sysctl) to avoid that.
Yes. But remember, the mail message pretents to be something like an e-card from a friend. You have to click on the link to see the e-card. Many naive users would really want to see the e-card their friend has sent (even though it is never mentioned who that friend may be) so they click the link. The next page explains they have to load some software. Not to unusual in the naive user's world. They visit websites all the time that tell them that they have to update their flash plugin, a codec, an active-x component, or whatever. They already click away those pop-ups that warn them before they have actually read them. Besides, the first page explains that they have to click OK and go through the installation or they will not be able to see the card. Who would want to turn down their friend and not view an e-card sent to them?
So the trojan is downloaded and installed. No problem, because they are logged in as an administrator. Who sets up their system to use separate accounts for admin and use? Maybe 1% of users try that.
So, the naive user very easily gets infected. Mainly because in the past they have seen so many useless pop-ups warning them about potentially harmful things that others have told them they should click away (like getting a warning when you delete something). A pop-up no longer is an alerting event that requires attention, it is just a stupid window that gets in the way of your "internet experience". Furthermore, most users are not prepared to think about security or to take extra steps to secure their systems (like using a separate account for software installation and system maintenance).
Slashdot Mirror
The reason it should be done in the file transfer utility is simple: by doing it there, you can write a utility for every system you want to communicate, and they will all be able to transfer files between eachother.
When you wanted to do it in "a little utility" you would have to write conversions for every kind of peer system into each of the utilities for all your systems, and when a new member joins the club you would have to update all the little utilties to support the new format.
Of course, what was dumb in FTP was the decision to let it use a conversion mode by default. It should have defaulted to "binary" and offer the option for conversions when the user specified them.
I think it is some plugin that makes ClamAV scan content that arrives by or is referred to in e-mail.
Maybe for Thunderbird or so.
For sure it is badly written. Without a Host: header it is doubtful that it gets the correct content to scan.
There is a similar pest from a virus scanner identifying as ClamAV 0.92.1
It retrieves URLs from our website but it does not include a Host: header with the requests it makes.
Of course this makes it fail on websites that use shared hosting on a single IP address.
We know how easy it is to stop botnet spam.
The problem is that the party that would have to implement the "solution" is not interested in solving the "problem", and neither do they want to be bothered with users who claim that they cannot mail because of something that has changed.
It always amazes me that botnet spam is so easy to identify and filter at the SMTP level.
The programmers that create those trojans and stealthy bots should be quite capable, yet the spamming payloads they (or others?) write to run on the botnets are lousy.
It seems like it is too much effort to read RFC-2821 and come up with a spambot that at least talks the SMTP protocol without stupid errors, and on the next level they are not very cleverly written either.
(e.g. most botnet spam is still blocked by simple greylisting, because the sender address is apparently generated randomly for every connection attempt)
When I started using Linux, the alternatives were Windows 3.11 and OS/2.
That was in december 1992. Windows 95 wasn't officially released until august 1995, nearly 3 years later.
In those days, Linux was already running X. I had a 486 with 16MB RAM and a graphic card with 1024x768 at 8 bits/pixel, but I remember that this system was performance-wise very competitive with the X terminals and VAX/VMS system at work.
It was actually quite amazing what had been accomplished with Linux in the few months since its creation (both in kernel functionality and getting existing applications compiled and working).
I work as normal user on XP all day, and so do all our users. Only incompetently managed XP systems provide "a very bad user experience" in that case. :-(
Most admins are not interested in finding out how to manage their systems, they prefer quick-and-dirty methods even when it hurts security. When they have tried to install Vista the first thing they are looking up on internet is how to get rid of those "allow or deny" popups
With a little more study of the matter they would be able to get their systems secured against exploits like this.
The flaw is causing drive-by malware downloads when an IE user simply browsers to a maliciously rigged Web page
Of course this flaw only affects badly managed systems where the user is browsing the Internet while logged on as an Adminstrator.
Microsoft is trying to discourage this but the users are too stupid to realize what they are doing wrong, and keep adding themselves to the Administrators group and keep trying to get rid of "annoying" popups that tell them they need to supply their password before the system will install software.
It would be sufficient when your workstations were setup a bit more securely, and you would not be working as an Administrator or Power User all day.
When using a Windows system as a normal user, those exploits do not stand a chance. That would be similar to using Linux as a normal user, not root.
Of course far too many wannabe-windows-admins have yelled "cannot do that, need to be admin to run many programs" because they found that in 2000 and never checked again.
That's why I mentioned only major sites. Look at what is having say 50kW-up of EIRP. Of course we had a couple of filler sites too, but fewer than in a hilly country.
But this should not hinder a digital conversion, it should HELP do do it.
In analog TV, you need a single path between your antenna and the site. And you need a unique channel for each of those paths. That is what requires the tedious planning and the many sites.
With digital TV (at least with DVB-T and COFDM as used in Europe) it all is different.
You can just flood the country with small transmitters operating in cities and townships, all on the same channel. Those transmitters will not be interfering with another, but they will help eachother to provide every viewer with a signal.
So what can be done is to first convert all major sites to digital as quickly as possible (due to manpower constraints), and then follow up with the minor sites that you still need, at leisure rate. Will be fewer than with analog, but local terrain situations will likely require filler sites.
In fact we now have two differently structured DVB-T networks operating. There is the broadcasting of public TV from the original locations of the analog network (tweaked a bit), i.e. tall towers and lots of power from relatively few locations. Alongside that there is a commercial (encrypted) network providing commercial stations as a pay-service. They use smaller sites at much lower locations, more like cell towers. It is intended for reception using indoor antennas. It existed before the analog switchoff.
I think the UK is not that different in this respect.
The story was about the UK. In Europe, we did not use component video in the past but almost every TV produced in the last two decades has an RGB input.
RGB is functionally equivalent to component. A Digital receiver usually outputs RGB and composite, which is connected to the TV via a SCART connector that combines composite video, audio and almost always RGB video in a single convenient connection.
The presence of an RGB input is so common because RGB is used for the "Teletext" feature available in almost every TV set, and the video multiplexer used to switch/combine the normal video and teletext signals operates at RGB signals and provides an extra RGB input for external signals.
(component video now appears on newer sets, but more because of compatability with equipment used in the USA than for real need)
It could be that our network was better maintained, better documented etc. We have had rules and regulations for a long time, that disallow the commercial operation of can-and-string cable networks. So our cable networks probably tend to be at a higher level.
(for example, cable networks don't get their signals by receiving the public broadcasting network so they were unaffected by this switch)
But in general, it can be said that a conversion like this can be done two ways: by endless debating about a transition period and then taking years, or by applying some pressure and be done with it.
Compared to the UK? I don't think so...
We had about 10 major transmitter sites each with 3 analog transmitters that were converted to a single digital multiplex overnight.
Later, more work has been done line converting from horizontal to vertical antenna polarization. But that is not really related to the actual conversion, but to the change to a more dense network with capability for indoor reception.
There is a big gap between doing everything on a single day, and taking 5 years to do it. That is not only explained by scale.
Maybe there is the assumption that people need more time to prepare. Get digital equipment, install it.
But spreading it over a 5 year period certainly will not help. Nobody is going to prepare for something that will happen in 2011 or 2012 in their region. All the preparation will be done in the month before the actual switchover in each area.
Analog signals are expected to have been switched off over the whole of the UK by 2012.
Why so slowly? Over here (Netherlands), analog signals have all been switched off in a single night last year, with the final decision having been made only a couple of months earlier. It was a simple matter of "what does it cost to keep the old system running, per viewer, and what is the cost for conversion to digital".
The fact that operating a digital TV transmitter wastes less energy might have weighed in too.
But that would leak pretty quickly, wouldn't it?
Just register a new domain, tell Google to spider it, and watch the logs for a while.
At first there will only be visits from Google. As time passes it will become more difficult, but you just register another domain.
plus it generates lots of electromagnetic noise from all the instant on-off action
Listen to what he explains in the beginnig of the video, about using a Palm Pilot because it is immune to the electromagnetic interference....
When being an NTP server you want the clock to be as accurate as possible.
The server is often locked to other servers and/or to local radio clock receivers.
In a physical machine, there is an accurate hardware timer that is used as the incrementing clock (at micro- or nanosecond rate) and which is frequency locked to the references.
Such hardware does not really exist in the virtual machine, it is emulated, and this emulation is not very good even when you sync to the host.
It is good enough for "wristwatch time" in your virtual machine, but in an NTP server you expect accuracy to the order of milliseconds when externally synced, or microseconds when synced to local radio receivers.
VMware simply is not up to that job.
Although I think ntpd does not have a bad security record (compared to other network services with a long history), I think a better approach to improved security would be to focus on the server code instead of running it in a virtual machine.
BTW, the current version already runs in a chroot environment and as a non-root user in modern Linux distributions.
This is how it works! Now, you just need more people who are prepared to be peers and serve the time for others.
NTP servers are written around precise clocks and with minumum processing latency in mind.
An NTP server running on a Windows platform already is significantly worse than one on Unix/Linux, and I think that should not be further degraded by running it in a virtual machine.
Remember you want to put the current local time down to nanoseconds in the reply packet. Your underlying platform should be capable of providing that time, and the processing code should not take so long that the time value is completely meaningless.
When you don't trust the program and don't want to put up a dedicated machine with no other critical stuff on it, then it is better to just forget about it.
It has been said many times that it would probably be a good idea to have a computer usage license similar to a driving license.
One that requires you to learn basic principles of secure computer use, and that can be withdrawn when excessive neglect leads to insecure situations and/or damages, just like is the case for a driving license.
The reason this is not yet in effect, is that driving a car is believed to be able to cause lethal injury, while using a computer isn't. But that is only for now.
When a large botnet is being used to attack certain internet sites and causes real damage and maybe death (like a terrorist attack), the situation could change.
I think it is quite scary that the current botnets are tolerated and mostly only their current effects (like SPAM) are combated. It would be much better when major ISPs would take strict measures against anyone found with a bot installed. It is quite easy to assemble lists of IP addresses of infected computers (many of those exist) but nobody does anything about it. Until it is too late and we come under a massive attack not so easily defeated as botnet SPAM, then we will hear that something should have been done.
The problem with Windows (recent versions) insecurity lies mainly in the user instead of the OS.
The basic design is quite good, but the average user spends his days working as an admin so all of the protection is effectively disabled.
It would be the same when all Linux users were working as root.
Usually a Linux installation procedure tries to convince you that you need a root acccount and a working user account, and often warnings are displayed when you try to use the GUI as root.
Similar things were tried with XP SP2 and more in Vista, but the users view it as a nuisance and there is a big demand for "solutions" to disable those popups that ask you to enter a password to do something stupid.
Probably when everyone switched to Linux, the same situation would arise, and it would not take long before similar botnets appeared.
Users are not interested in security. They don't see the need, and they hate the extra effort required.
No. A TCP connection does not put load on routers.
The reason is that to block a packet you need a device that passes-through packets and could get overwhelmed or be broken, while with the RST method you just need to examine pass-by traffic and send an occasional RST. When your device gets overloaded, it will just miss part of the traffic but the traffic itself will not be hindered.
This will not accomplish much.
/proc or sysctl) to avoid that.
For one, in Linux the process priority us dynamically adjusted. So a program that hogs the CPU will automatically decrease in priority so that it gets all CPU time remaining after other processes that use little CPU have got their share. It will not really starve lower-priority processes, as happens on a completely priority determined scheduler with static priorities (found in realtime kernels, in Windows NT, etc).
But, another issue is that a process that makes the system slow by allocating lots of memory and causing lots of paging to disk (as described here) is not a CPU hog and will thus not be controlled by the process priority. Even at a very low priority, such tasks can still slowdown the system.
You need tuning of the system parameters (via
I'm surprised that the GUI doesn't get priority over this sort of runaway process
That is because the GUI is just a set of processes running under the same mechanism, not some special part of the kernel or something like that.
Yes. But remember, the mail message pretents to be something like an e-card from a friend. You have to click on the link to see the e-card.
Many naive users would really want to see the e-card their friend has sent (even though it is never mentioned who that friend may be) so they click the link.
The next page explains they have to load some software. Not to unusual in the naive user's world. They visit websites all the time that tell them that they have to update their flash plugin, a codec, an active-x component, or whatever. They already click away those pop-ups that warn them before they have actually read them.
Besides, the first page explains that they have to click OK and go through the installation or they will not be able to see the card. Who would want to turn down their friend and not view an e-card sent to them?
So the trojan is downloaded and installed. No problem, because they are logged in as an administrator. Who sets up their system to use separate accounts for admin and use? Maybe 1% of users try that.
So, the naive user very easily gets infected. Mainly because in the past they have seen so many useless pop-ups warning them about potentially harmful things that others have told them they should click away (like getting a warning when you delete something). A pop-up no longer is an alerting event that requires attention, it is just a stupid window that gets in the way of your "internet experience".
Furthermore, most users are not prepared to think about security or to take extra steps to secure their systems (like using a separate account for software installation and system maintenance).