I'm not buying Team Viewers explaination one bit. I know the individual in this article. He's a fellow security expert with whom I've worked. He's no security slouch, quite the opposite in fact. He caught the attackers in the act (yeah, he got lucky there) and took action as it unfolded before his eyes. Team Viewer has some serious 'splainen to do...
Canonical and Ubuntu left me no choice. With Wayland and Unity, they totally broke NX remote desktops in a way that made it virtually (sic) impossible to fix, even where the freenx package was still in the repositories (some audio lib dependencies could not be satisfied). Even going with Xubuntu failed due to dependency failures in these media libraries that could no longer even be install from external repos or built from scratch! I couldn't even compile from source. Finally ripped all Ubuntu off all of my systems, servers, laptops et al. There was simply no option to have Ubuntu on a system and loosing my NX remote desktop capability. So Ubuntu had to go.
Fedora et al with Gnome3 and systemd are not far behind. Sigh... I've had to resort to XFCE with the old Enlightement 16 window manager to avoid the brokeness of Gnome3.
That also fails the prior art test since a lot of audio equipment is equipped with SPDIF ports that have an electrical coax connector shell and a fiberoptic core. So you can plug in either a coax SPDIF digital audio cable or a fiberoptic one. Two well documented standard cables and one port.
I think Cisco/Linksys may have some contrary prior art.
Some Linksys WiFi routers would seen to meet that description. There's a "hidden serial console port" on the WTR-610N WiFi routers for the serial access port. It's on the opposite side of the LAN1 port. You wire a special ethernet connector up with a 4 wire cable on top (tap side) of the ethernet plug and it mates with circuit board contacts giving you a TTL level serial for reprogramming and a controlling console.
That router has been around for quite a few years. There certainly may be others. They produced a number of models of the same footprint and form factor over the years.
I just happen to own a couple of these myself (and yes managed to brick and recover one). References and descriptions can be found on the dd-wrt web site forums where they've documented it.
Sorry, no. Your defintion (or your understanding) of a 0-day is faultly. The security community accepts that, a zero-day or oh-day is a vulnerabily for which an exploit exists in circulation and for which no patch or workaround is available. It takes "zero days" to exploit. It doesn't matter if the vendor has know about it for 10 minutes or 10 years. It's an 0-day if it takes you that long to pown them...
One of the comments in the post this links to claims that it's an urban legend and I think that maybe correct. I remember those times and was an avid follower. Even the earliest Apollo missions had a "go round" bailout if they aborted a landing. Not sure you would call that a "sling shot" but they did know full well the trajectories.
This is an old issue and people have done it better for a long time. The vendors (MS included) CHOSE to use half hearted, stupid, and short sighted solution. I saw proposal papers over a decade ago at the ISOC (Internet Society) NDSS conference:
Right. This is why you root your phone. It's to de-crappify it. You take that crap off. I love Cyanogen Mod! Shouts to Cyanogen and congrats on the new job!
Vendors of phones and network providers refuse to accept the very concept that you own your bloody phone and have a right to do with it what you want. It's the Bell system from the '60's and earlier (pre AT&T divestiture) all over again. They get to tell you what you can do with your property and you will smile and you will like it.
Apple is even worse. They will dictate your entire experience and, if they are not happy with an applications which does not meet their agenda, politically or socially, they will cut them off. They take dictatorship and crapware to a whole new realm of reality. Oh well...
I opt for freedom.
Several of the vendors have gotten on the clue train. HTC is there. Samsung hired Cyanogen and is opening THEIR bootroms. Motorola (soon to be Google, maybe) fought it but threw in the towel and announced they would unlock their boot roms. They ARE getting it. The VENDORS are getting it. The carriers are NOT as yet. The clue train has not arrived for them. We need to teach them and we need to teach them a painful lesson. If it costs them money to kept their hands on our short and curlies, eventually they will get a clue and release their grip. AT&T sucks. They want to extend their control as much for the money as to dominate you and dictate to you where you have no option. That's mind control. That's corporate 1984. That's what we call a "monopoly" and that's what has to be prevented.
ITMT... It is established law that you have a right to root your phones (DMCA exemption as determined by the library of congress...)
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
Yeah, I'll give it a shot.
First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.
Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.
With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).
Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.
Yeah, especially when you have clowns like OpenDNS saying they won't support, or even pass through, DNSsec because they like DNS Curve better. The two standards (and I say that loosely because DNS Curve is NOT a standard and no where close) solve different problem sets but OpenDNS is too dense to realize that.
Well... The fact that it became known does not speak much for their secrecy, and secrecy in this regard is a very relative term, even if the group ever intended it to be a "secret society Illuminate". Sometimes (and I've seen it happen all too often) someone accuses people of discussing things "in secret" only because they weren't a member and the membership signup was not obvious to a 3 year old. Without knowing more about the specific list and group, it is impossible to judge their motives based on an unsubstantiated claim of a "secret mailing list".
I've been a member of "closed" mailing lists before and continue to be to this day. It's generally a question of someone vouching for you. Example... In the dark early days of the Internet and the Robert Morris Worm incident, we had two parallel security lists. To get on the Zardoz list, you merely had to sign up. To get on the ISIS list, you had to have some vouch for you in the "bang path" (uucp notation) between you and them.
More recently, certain mailing lists, such as the recently defunct VendorSec mailing list,. required a discussion amongst the members for you to join. Especially, in security circles, there's a matter of trust and reputation and the very real problems of disruptors , some of whom are "state sponsored" (the government really doesn't like it when you can protect your privacy and your security - you should depend on them for that, right? They long for their good old days of ITAR). Sometimes (SERIOUSLY) some of those lists are there discussing things of a serious enough nature that we don't want the "bad guys" to have a heads up. Some of us have to collaborate in a trusted manner somehow and, yes, we're going to get accused of "operating in secret". But it's just a matter of knowing who you are communicating with and can trust them. This doesn't sound like that kinda list but I would love to know what list it was. There are probably a dozen or more lists on the net right now discussing this very issue, probably including one or more IETF lists. It's generally not a "cabal" and I've never found it hard to join one if you have the reputation to be trusted.
Domain Validation (DV) certs are not the same as OV, Organizational Validation, or EV, Extended Validation, certs. Web SSL certs are OV or EV. DV certs are intended to validate that the FQDN is valid (i.e. correctly owned by the domain). This is the job that DNSsec is meant to address in many ways. There's already been public discussion on some of the crypto forums such as mozilla-crypto (ok, for some value of "public" - but it's not a closed list). The DNSsec crowd have asked about putting certificate signatures in DNSsec and the entrenched CA crowd got all up and in arms and huffy about it. But DV certs would just tie the certs to the domain owners, and that's all, which is exactly what can be done in DNSsec. And, yes, we all know, the domain could be faked but that's not the point. The point is to tie a certificate back to the domain owner or not. The OV/EV certs are what validate the organization claiming to own the domain/FQDN. The CA crowd doesn't like the fact that DNSsec can do for free what they can charge money for. DNSsec puts the power totally in the hands of the domain owners (where it bloody well belongs). Now if we could just get certain bloody registrars, like Network Solutions, to let us register our key signing keys, we could get on with things. The root zone (.) is signed. The.org,.net,.com,.edu, and.gov zones are all signed and numerous other ccTLDs are signed. Godaddy and others are reported to be accepting DNSsec registrations. Where is Network Solutions? A sleep at the switch last I looked. And OpenDNS continues to pout, whining "I donwanna... Use DNS Curve or I'm gonna cry." DV certs are a solution in search of a problem and DNSsec is a better solution.
Looks like those include the zBoost units. I have one for Sprint. Love it. I can see the signal improvement powering up the unit. I got mine from SmartHome and can highly recommend them. Just be sure to get the right unit for your band.
If what you're after is a cell phone extender, then I can highly recommend the Wireless Extender Cell Phone Signal Booster from SmartHome. They are NOT cheap (> $200 single band. >300 for the dual band unit). But, after laying my money down and running the wireless antenna up into my attic with the repeater system and antenna down in the basement, I can honestly say, I've got a better cell phone signal in my basement than upstairs on the main floor or even the second floor. Be mindful that you get the right unit for your band / service. I got one that works with Sprint and I love it. Works with my 3G data network and data card from them as well (as would be expected - it's just cellular). Comes with enough cable to span two stories up into an attic from a basement.
I'm the author of a number of patches to a number of OSS projects, mostly security related. So, I would love to know what this "authentication module" is. Sounds like it might be PAM or maybe Apache related?
Over the last year and half or so, a major OSS routing package, Quagga, was largely on "auto pilot". The maintainer was not being responsive and outstanding patches were piling up and releases were over due. This project was, in and of itself a fork of an earlier project, Zebra, that had gone stale and been largely abandoned by its developers. Several months ago he popped up back out of the woodwork explaining that his job (that supported his work on this project) had been overwhelming and he had gotten way behind in things. Since then, most of the patches that had piled up in his queue have been integrated and several releases have cycled out and the project is now approaching it's first 1.0 release candidate. That project is alive and active once again but, before he returned some people were already starting to talk of yet another fork.
It happens and it can take time. If the project has a list, post to it and seek out some of the past contributors. Don't give up on him, he may be just extremely busy putting food on the table. The entire CentOS distribution was threatened by the absence of their lead (covered in other SlashDot articles). He showed up after all the publicity.
On the other hand, some projects deserve to die. A couple of VPN projects and crypto projects have been abandoned by their authors and maintainers and don't deserve to be resurrected (bugs, security holes, etc) even though they still had followers. Doesn't sound to be the case here but it's hard to tell without knowing what it is.
Perhaps you should rethink that mistake and create a real "master" and make them "slaves". The system was designed this way for a reason. It baffles me why people do things this this way.
A server behind a firewall does not imply a server on a private network. You can have firewalls in front of a DMZ on a public address providing services. Firewalls are used for much more than merely "private networks". Those are two orthogonal issues.
OTOH... A master on a private network providing zone feeds to slaves on various other networks (firewalled or not) on public addresses would be a very good idea.
From the advisory: "Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert."...
So an obvious workaround is to only expose your slave DNS servers and to not expose your master server to the Internet. That's part of "best common practices" isn't it? You have one master and multiple slaves and you protect that master. Come on, this is pretty simple stuff. Just simple secure DNS practices should mitigate this. Yeah, if you haven't done it that way to begin with, you've got a mess on your hands converting and it's easier to patch. But patch AND fix your configuration.
No experience with it, I just happened to be looking at the freshmeat announcement a couple of days ago.
Features:
* Video/Audio
* See Desktop of any participant
* Multi-Language and Customizable
* Whiteboard with drawing, write & edit, dragNDrop, Resizeing, Images (DragNDrop from Library), Symbol(s)
* Conference while drawing (4x4 or 1xn modus)
* Safe Drawings / whiteboard and load it next time, edit and resave
* Import Documents (.tga,.xcf,.wpg,.txt,.ico,.ttf,.pcd,.pcds,.ps,.psd,.tiff,.bmp,.svg,.dpx,.exr,.jpg,.jpeg,.gif,.png,.ppt,.odp,.odt,.sxw,.wpd,.doc,.rtf,.txt,.ods,.sxc,.xls,.sxi,.pdf) DocumentImporting
* Send invitation and direct Links into a meeting
* Moderating System
* User-/Organisation-/Moderating- System
* Backup and Language Module (LanguageEditor, BackupPanel)
* Private and Public (Organisation only) Conference-Rooms
* Technologies used, see TechnologyPortfolio
I was going to complain it wasn't a global unicast address (2000::/16 - 3fff::/16) but yours was better. I suppose they meant it to be 5EC instead of sec which would have been more 31337.
Oh well... Good job...
Damn... Even got mod points and I can't both mod and post/reply... Sigh... >;-P
Slashdot Mirror
I'm not buying Team Viewers explaination one bit. I know the individual in this article. He's a fellow security expert with whom I've worked. He's no security slouch, quite the opposite in fact. He caught the attackers in the act (yeah, he got lucky there) and took action as it unfolded before his eyes. Team Viewer has some serious 'splainen to do...
https://securityintelligence.c...
Canonical and Ubuntu left me no choice. With Wayland and Unity, they totally broke NX remote desktops in a way that made it virtually (sic) impossible to fix, even where the freenx package was still in the repositories (some audio lib dependencies could not be satisfied). Even going with Xubuntu failed due to dependency failures in these media libraries that could no longer even be install from external repos or built from scratch! I couldn't even compile from source. Finally ripped all Ubuntu off all of my systems, servers, laptops et al. There was simply no option to have Ubuntu on a system and loosing my NX remote desktop capability. So Ubuntu had to go.
Fedora et al with Gnome3 and systemd are not far behind. Sigh... I've had to resort to XFCE with the old Enlightement 16 window manager to avoid the brokeness of Gnome3.
That also fails the prior art test since a lot of audio equipment is equipped with SPDIF ports that have an electrical coax connector shell and a fiberoptic core. So you can plug in either a coax SPDIF digital audio cable or a fiberoptic one. Two well documented standard cables and one port.
I think Cisco/Linksys may have some contrary prior art.
Some Linksys WiFi routers would seen to meet that description. There's a "hidden serial console port" on the WTR-610N WiFi routers for the serial access port. It's on the opposite side of the LAN1 port. You wire a special ethernet connector up with a 4 wire cable on top (tap side) of the ethernet plug and it mates with circuit board contacts giving you a TTL level serial for reprogramming and a controlling console.
That router has been around for quite a few years. There certainly may be others. They produced a number of models of the same footprint and form factor over the years.
I just happen to own a couple of these myself (and yes managed to brick and recover one). References and descriptions can be found on the dd-wrt web site forums where they've documented it.
Sorry, no. Your defintion (or your understanding) of a 0-day is faultly. The security community accepts that, a zero-day or oh-day is a vulnerabily for which an exploit exists in circulation and for which no patch or workaround is available. It takes "zero days" to exploit. It doesn't matter if the vendor has know about it for 10 minutes or 10 years. It's an 0-day if it takes you that long to pown them...
One of the comments in the post this links to claims that it's an urban legend and I think that maybe correct. I remember those times and was an avid follower. Even the earliest Apollo missions had a "go round" bailout if they aborted a landing. Not sure you would call that a "sling shot" but they did know full well the trajectories.
This is an old issue and people have done it better for a long time. The vendors (MS included) CHOSE to use half hearted, stupid, and short sighted solution. I saw proposal papers over a decade ago at the ISOC (Internet Society) NDSS conference:
Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
Andrea Rierra and Joan Boerrell
http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/riera.pdf
Start there and get serious.
Right. This is why you root your phone. It's to de-crappify it. You take that crap off. I love Cyanogen Mod! Shouts to Cyanogen and congrats on the new job!
Vendors of phones and network providers refuse to accept the very concept that you own your bloody phone and have a right to do with it what you want. It's the Bell system from the '60's and earlier (pre AT&T divestiture) all over again. They get to tell you what you can do with your property and you will smile and you will like it.
Apple is even worse. They will dictate your entire experience and, if they are not happy with an applications which does not meet their agenda, politically or socially, they will cut them off. They take dictatorship and crapware to a whole new realm of reality. Oh well...
I opt for freedom.
Several of the vendors have gotten on the clue train. HTC is there. Samsung hired Cyanogen and is opening THEIR bootroms. Motorola (soon to be Google, maybe) fought it but threw in the towel and announced they would unlock their boot roms. They ARE getting it. The VENDORS are getting it. The carriers are NOT as yet. The clue train has not arrived for them. We need to teach them and we need to teach them a painful lesson. If it costs them money to kept their hands on our short and curlies, eventually they will get a clue and release their grip. AT&T sucks. They want to extend their control as much for the money as to dominate you and dictate to you where you have no option. That's mind control. That's corporate 1984. That's what we call a "monopoly" and that's what has to be prevented.
ITMT... It is established law that you have a right to root your phones (DMCA exemption as determined by the library of congress...)
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
Yeah, I'll give it a shot.
First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.
Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.
With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).
Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.
And how is this (which requires to pay money to a CA) any better than certs with the key fingerprints / signatures in DNSsec (which is free)?
Yeah, especially when you have clowns like OpenDNS saying they won't support, or even pass through, DNSsec because they like DNS Curve better. The two standards (and I say that loosely because DNS Curve is NOT a standard and no where close) solve different problem sets but OpenDNS is too dense to realize that.
Well... The fact that it became known does not speak much for their secrecy, and secrecy in this regard is a very relative term, even if the group ever intended it to be a "secret society Illuminate". Sometimes (and I've seen it happen all too often) someone accuses people of discussing things "in secret" only because they weren't a member and the membership signup was not obvious to a 3 year old. Without knowing more about the specific list and group, it is impossible to judge their motives based on an unsubstantiated claim of a "secret mailing list".
I've been a member of "closed" mailing lists before and continue to be to this day. It's generally a question of someone vouching for you. Example... In the dark early days of the Internet and the Robert Morris Worm incident, we had two parallel security lists. To get on the Zardoz list, you merely had to sign up. To get on the ISIS list, you had to have some vouch for you in the "bang path" (uucp notation) between you and them.
More recently, certain mailing lists, such as the recently defunct VendorSec mailing list,. required a discussion amongst the members for you to join. Especially, in security circles, there's a matter of trust and reputation and the very real problems of disruptors , some of whom are "state sponsored" (the government really doesn't like it when you can protect your privacy and your security - you should depend on them for that, right? They long for their good old days of ITAR). Sometimes (SERIOUSLY) some of those lists are there discussing things of a serious enough nature that we don't want the "bad guys" to have a heads up. Some of us have to collaborate in a trusted manner somehow and, yes, we're going to get accused of "operating in secret". But it's just a matter of knowing who you are communicating with and can trust them. This doesn't sound like that kinda list but I would love to know what list it was. There are probably a dozen or more lists on the net right now discussing this very issue, probably including one or more IETF lists. It's generally not a "cabal" and I've never found it hard to join one if you have the reputation to be trusted.
Domain Validation (DV) certs are not the same as OV, Organizational Validation, or EV, Extended Validation, certs. Web SSL certs are OV or EV. DV certs are intended to validate that the FQDN is valid (i.e. correctly owned by the domain). This is the job that DNSsec is meant to address in many ways. There's already been public discussion on some of the crypto forums such as mozilla-crypto (ok, for some value of "public" - but it's not a closed list). The DNSsec crowd have asked about putting certificate signatures in DNSsec and the entrenched CA crowd got all up and in arms and huffy about it. But DV certs would just tie the certs to the domain owners, and that's all, which is exactly what can be done in DNSsec. And, yes, we all know, the domain could be faked but that's not the point. The point is to tie a certificate back to the domain owner or not. The OV/EV certs are what validate the organization claiming to own the domain/FQDN. The CA crowd doesn't like the fact that DNSsec can do for free what they can charge money for. DNSsec puts the power totally in the hands of the domain owners (where it bloody well belongs). Now if we could just get certain bloody registrars, like Network Solutions, to let us register our key signing keys, we could get on with things. The root zone (.) is signed. The .org, .net, .com, .edu, and .gov zones are all signed and numerous other ccTLDs are signed. Godaddy and others are reported to be accepting DNSsec registrations. Where is Network Solutions? A sleep at the switch last I looked. And OpenDNS continues to pout, whining "I donwanna... Use DNS Curve or I'm gonna cry." DV certs are a solution in search of a problem and DNSsec is a better solution.
Looks like those include the zBoost units. I have one for Sprint. Love it. I can see the signal improvement powering up the unit. I got mine from SmartHome and can highly recommend them. Just be sure to get the right unit for your band.
Yeah, these are the ones available from SmartHome. I agree! They work great.
If what you're after is a cell phone extender, then I can highly recommend the Wireless Extender Cell Phone Signal Booster from SmartHome. They are NOT cheap (> $200 single band. >300 for the dual band unit). But, after laying my money down and running the wireless antenna up into my attic with the repeater system and antenna down in the basement, I can honestly say, I've got a better cell phone signal in my basement than upstairs on the main floor or even the second floor. Be mindful that you get the right unit for your band / service. I got one that works with Sprint and I love it. Works with my 3G data network and data card from them as well (as would be expected - it's just cellular). Comes with enough cable to span two stories up into an attic from a basement.
Works with all 800 MHz cellular phone systems (Verizon)
http://www.smarthome.com/9625C/Wireless-Extender-zBoost-Cell-Phone-Signal-Booster-for-CEL-Phones-YX500-CEL/p.aspx
Works with all 1900 MHz PCS-based phone systems (Sprint, NexTel)
http://www.smarthome.com/9625/Cell-Phone-Signal-Booster-YX500-PCS/p.aspx
Works with both 1900 MHz PCS-based phones AND 800 MHz cell-based phones
http://www.smarthome.com/9631/Wireless-Extender-zBoost-Home-Office-Cell-Phone-Signal-Booster-Unit/p.aspx
I'm the author of a number of patches to a number of OSS projects, mostly security related. So, I would love to know what this "authentication module" is. Sounds like it might be PAM or maybe Apache related?
Over the last year and half or so, a major OSS routing package, Quagga, was largely on "auto pilot". The maintainer was not being responsive and outstanding patches were piling up and releases were over due. This project was, in and of itself a fork of an earlier project, Zebra, that had gone stale and been largely abandoned by its developers. Several months ago he popped up back out of the woodwork explaining that his job (that supported his work on this project) had been overwhelming and he had gotten way behind in things. Since then, most of the patches that had piled up in his queue have been integrated and several releases have cycled out and the project is now approaching it's first 1.0 release candidate. That project is alive and active once again but, before he returned some people were already starting to talk of yet another fork.
It happens and it can take time. If the project has a list, post to it and seek out some of the past contributors. Don't give up on him, he may be just extremely busy putting food on the table. The entire CentOS distribution was threatened by the absence of their lead (covered in other SlashDot articles). He showed up after all the publicity.
On the other hand, some projects deserve to die. A couple of VPN projects and crypto projects have been abandoned by their authors and maintainers and don't deserve to be resurrected (bugs, security holes, etc) even though they still had followers. Doesn't sound to be the case here but it's hard to tell without knowing what it is.
Perhaps you should rethink that mistake and create a real "master" and make them "slaves". The system was designed this way for a reason. It baffles me why people do things this this way.
A server behind a firewall does not imply a server on a private network. You can have firewalls in front of a DMZ on a public address providing services. Firewalls are used for much more than merely "private networks". Those are two orthogonal issues.
OTOH... A master on a private network providing zone feeds to slaves on various other networks (firewalled or not) on public addresses would be a very good idea.
This isn't Windows...
# yum -y update named\* && service named restart
(Not sure if yum [or apt] would restart named and NOT willing to take the chance.)
How would that help with this? You don't even need dynamic updates enabled for this to be exploited.
From the advisory: "Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert."...
So an obvious workaround is to only expose your slave DNS servers and to not expose your master server to the Internet. That's part of "best common practices" isn't it? You have one master and multiple slaves and you protect that master. Come on, this is pretty simple stuff. Just simple secure DNS practices should mitigate this. Yeah, if you haven't done it that way to begin with, you've got a mess on your hands converting and it's easier to patch. But patch AND fix your configuration.
http://code.google.com/p/openmeetings/
.xcf, .wpg, .txt, .ico, .ttf, .pcd, .pcds, .ps, .psd, .tiff, .bmp, .svg, .dpx, .exr, .jpg, .jpeg, .gif, .png, .ppt, .odp, .odt, .sxw, .wpd, .doc, .rtf, .txt, .ods, .sxc, .xls, .sxi, .pdf) DocumentImporting
No experience with it, I just happened to be looking at the freshmeat announcement a couple of days ago.
Features:
* Video/Audio
* See Desktop of any participant
* Multi-Language and Customizable
* Whiteboard with drawing, write & edit, dragNDrop, Resizeing, Images (DragNDrop from Library), Symbol(s)
* Conference while drawing (4x4 or 1xn modus)
* Safe Drawings / whiteboard and load it next time, edit and resave
* Import Documents (.tga,
* Send invitation and direct Links into a meeting
* Moderating System
* User-/Organisation-/Moderating- System
* Backup and Language Module (LanguageEditor, BackupPanel)
* Private and Public (Organisation only) Conference-Rooms
* Technologies used, see TechnologyPortfolio
Deprecated. Alone with ip6.int, bit fields for reverse look-ups, and site local addresses. Nice ideas that didn't work out in practice.
NICE CATCH!
I was going to complain it wasn't a global unicast address (2000::/16 - 3fff::/16) but yours was better. I suppose they meant it to be 5EC instead of sec which would have been more 31337.
Oh well... Good job...
Damn... Even got mod points and I can't both mod and post/reply... Sigh... >;-P