Re: Intel Microcode updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, >>>> On 12/6/19 3:16 am, Holger Levsen wrote: >>>>> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan >>>>> wrote: >>>>>> Exploiting the flaws needs malicious code to be running >>>>>> on your box. If you are in total control over all VMs >>>>>> and processes on the box, then you should be good. >>>>> do you use a webbrowser with javascript enabled? >>>> Good point, yes that is another risk. > Actually though, if you update your browser to lessen the > granularity of time that the exploits require, it might not be an > issue. So, don't run an out of date browser is that enough? It doesn't have to be JavaScript, it can be ANY scripting. When it comes to an updated browser, the exploit relies upon very precise timing differences between operations -- if the browser won't report timing with enough precision, then the exploit cannot work reliably if at all (probably not at all). Now as for TB, well, one would hope (I don't now the answer), that they too have implemented the same fixes that Mozilla made for Firefox to thwart the success of an exploit as well, ie have timing being less granular to be able to perform the exploit. Anyway, if the CPU microcode can be attained for the older CPUs, then the licensing issue with Debian providing it is no longer a concern (I believe). Refer https://01.org/mcu-path-license-2018 Cheers A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQkrpQAKCRCoFmvLt+/i +zHAAP4nK5G7HuNv+YzJBjb0aU4e06faITqYO4/pVxARNed8BQD/ZygkaIizLAte 0MuzlcPSQSjN04zlTUo9gxqD18ttbAE= =21rJ -END PGP SIGNATURE-
Re: Intel Microcode updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, > On 12/6/19 3:16 am, Holger Levsen wrote: >> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan >> wrote: >>> Exploiting the flaws needs malicious code to be running on your >>> box. If you are in total control over all VMs and processes >>> on the box, then you should be good. > >> do you use a webbrowser with javascript enabled? > > Good point, yes that is another risk. Actually though, if you update your browser to lessen the granularity of time that the exploits require, it might not be an issue. So, don't run an out of date browser is that enough? Cheers A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i +2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI= =/5dj -END PGP SIGNATURE-
Re: Intel Microcode updates
Hi Russell, On 11/6/19 12:19 pm, Henrique de Moraes Holschuh wrote: > On Mon, 10 Jun 2019, Russell Coker wrote: >> model name : Intel(R) Core(TM)2 Quad CPUQ9505 @ 2.83GHz The first thing to think about with all of these problems is, are you /really/ affected ie, are you at risk? Now, if you run your own machine and you trust EVERY process on that machine, then you should be safe. This is extended if you have VMs on the machine, you have to trust EVERY SINGLE process on every VM. Exploiting the flaws needs malicious code to be running on your box. If you are in total control over all VMs and processes on the box, then you should be good. The trouble comes when you have an non-trusted process or VM or a trust that has been broken. If you share a machine that you are not in control of, others using that same (physical) machine, will then you are at risk. Of course, at any time, if there is some other vulnerability that comes in to play and a process can run that should not be ran, then you are at risk. Kind Regards AndrewM
Re: Shellshock: Has CVE-2014-7186 and CVE-2014-7187 been addressed for debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/09/2014 4:29 AM, Martin Holub wrote: Please according to the Security Tracker [1,2] booth are fixed in stable and oldstable. NOT QUITE . fixed in stable [wheezy] and oldstable-LTS [squeeze-lts] BUT NOT oldstable [squeeze] it is NOT fixed, nor is it still supported. :( Cheers A. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlQnHwcACgkQqBZry7fv4vvwvwEAvyOLseQFtGPpRVgKACCMJLz0 TDB8s+yhSRm1B6hF7N8A/2EtYBzUYE27bOiJPy5Wd9v2hf6K1iZNBnhnOhp8gpS6 =CYzm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54271f09.8010...@affinityvision.com.au
Re: [SECURITY] [DSA 2939-1] chromium-browser security update
On 1/06/2014 5:13 AM, Andrew McGlashan wrote: The OCSP server not found issue is rare, in the past the /main/ CA's got together to discuss the OCSP issue and they create CDN's to deal with issues like not being able to connect the OCSP server. The page that was linked from /google's/ pov ... was quite old btw. Of the sites that have trouble with OCSP, the most significant ones for me have been Google search and Youtube when Google Search fails, I just use another search engine. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53921104.9000...@affinityvision.com.au
Re: [SECURITY] [DSA 2939-1] chromium-browser security update
On 31/05/2014 7:27 PM, Georgi Naplatanov wrote: On 05/31/2014 10:27 AM, Michael Gilbert wrote: - Debian Security Advisory DSA-2939-1 secur...@debian.org http://www.debian.org/security/ Michael Gilbert May 31, 2014 http://www.debian.org/security/faq - Does Chromium suffer from the Google decision to make use of OCSP impossible? Therefore, an untrustworthy browser. Thanks A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5389c0b1.7000...@affinityvision.com.au
Re: [SECURITY] [DSA 2939-1] chromium-browser security update
On 1/06/2014 12:31 AM, Michael Gilbert wrote: On Sat, May 31, 2014 at 7:44 AM, Andrew McGlashan wrote: Does Chromium suffer from the Google decision to make use of OCSP impossible? Therefore, an untrustworthy browser. Basically, the answer is the design of certificate revocation is fundamentally flawed, and Google have their own security model: http://www.imperialviolet.org/2012/02/05/crlsets.html That should not in any way lead to the conclusion that chromium or google chrome are untrustworthy. It just means that Google uses an alternative approach to a fundamentally unsolvable problem. Absolutely you cannot trust Google's method of placing a bandaid on the problem. There are about a days worth of revoked certificates in CRLset .. that is far from sufficient for certs that can be up to 10 years old, albeit most are 1 or 2 years. OCSP is far superior than CRLset and even better when you force a response to be required -- which is possible, but not default with Firefox. We may see certificate stapling as an answer, but that won't be enough if it cannot be certified to /require/ stapling in the cert itself. There may be other solutions in time. You are right in saying that the whole certificate revocations model is flawed, but not as flawed as what Google is choosing to use in CRLset. Quite simply, Google's response to this problem is a joke. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538a157b.2070...@affinityvision.com.au
Re: [SECURITY] [DSA 2939-1] chromium-browser security update
On 1/06/2014 4:35 AM, Michael Gilbert wrote: On Sat, May 31, 2014 at 1:46 PM, Andrew McGlashan wrote: We may see certificate stapling as an answer, but that won't be enough if it cannot be certified to /require/ stapling in the cert itself. There may be other solutions in time. You are right in saying that the whole certificate revocations model is flawed, but not as flawed as what Google is choosing to use in CRLset. Quite simply, Google's response to this problem is a joke. It sounds like you've got a stinging itch there, so feel empowered to go scratch it. I'm sure Google would be interested in a nice patch set solving this problem once and for all. Google did have OCSP, but they deliberately removed it recently. FWIW, Steve Gibson has a very good take on all of this. The OCSP server not found issue is rare, in the past the /main/ CA's got together to discuss the OCSP issue and they create CDN's to deal with issues like not being able to connect the OCSP server. The page that was linked from /google's/ pov ... was quite old btw. Google pushed back on OCSP when Steve Gibson had much to say about the whole revocation mess and he talked about alternative ideas that the industry is considering. The CA's backed Steve's take and can't seem to understand why Google would push back so hard to go against the OCSP idea and other possible solutions. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538a29be.2020...@affinityvision.com.au
Re: goals for hardening Debian: ideas and help wanted
On 24/04/2014 5:49 PM, Lesley Binks wrote: Apologies for the top posting, I'm writing this from my phone. I get a 403 when trying to access via Orbot/Orweb on Android 4.1 phone. Amusing. It works for me [Orbot/Orweb -- 4.3 on both i9300 and i9505], did you get the case right? Strangely though my i9300 wouldn't use Tor properly until I rebooted it; Orbot said it was fine, but Orweb gave my public IP address! It was fine after a reboot, but I don't know why that was necessary. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5358e019.7090...@affinityvision.com.au
Re: NSA software in Debian
On 25/01/2014 7:39 PM, Emmanuel Thierry wrote: Then DNSSEC appeared ! :) I wish it was that simple I don't believe it is today, but one day it will have to be the standard. I remind you it is really difficult to compromise DNS zones protected by DNSSEC, even if you have control on root DNS servers (they probably have it) and the knowledge of the complete root DNS key (they likely don't have it). There is no point in considering DNS as compromised, since it would be much easier (and as difficult to hide) to subvert IP routing. By the way if you succeeded in redirecting DNS traffic to your box, you probably have the power of redirecting all the traffic to your box. It is technically very easy to compromise DNS for many people. It often surprises me that people don't question absolutely whether or not a webpage is legitimate, they almost always take it on faith unless there is something very obviously wrong and even then the person will take some convincing (especially the lesser educated on these matters). Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e5544a.4070...@affinityvision.com.au
Re: NSA software in Debian
Hi, On 19/01/2014 6:30 AM, Marco Saller wrote: i am not sure if this question has been asked or answered yet, please do not mind if i would ask it again. Is it possible that the NSA or other services included investigative software in some Debian packages? I've read all the posts so far in this and related threads (each tree of this top thread actually). It is definitely not beyond the realms of possibility that hardware is compromised WORLDWIDE, from hardware additions to firmware /adjustments/. It might not be cheap to compromise as many machines as you want, but it might be cheaper to consider every machine a possible target, so the NSA could modify every single machine they could get their hands on and many that they can remotely access via other means. There are problems at every level, including hard drive firmwares, ordinary looking USB cables, tricked VGA leads ... and these revaluations come from a document with a date of 2008. Also, it is not impossible for *any* organization to have a /ghosted/ version; we might be installing Debian from a ghost version of Debian that is compromised and for all intents and purposes, it appears 100% to be Debian. DNS can be taken over at any point to allow the /ghost/ version to be *the* version that any one of us sees. Every single machine on the Internet can be impersonated, particularly if you have the budget of the NSA and the right access possibilities. Heck, as I understand it, even the NSA can return DNS results more quickly than official sources due to placement of their own /black/ boxes to subvert any DNS request on the planet and point people to a ghosted version of anything... There is no definitive answer other than, the NSA has screwed so many that it is impossible to have trust; even when the likes of Google outwardly show rage and disgust over NSA actions, there is nothing to give us total faith in Google either, heck they can be ghosted too. However, given all the very real possibilities, I would like to believe that in Debian, we can trust, but OTOH it just might be misplaced through no fault of anyone [at all] involved with official Debian activities in any way. It's virtually impossible to know one way or another, we just have to have some faith and trust (perhaps too much of one or both). Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e26806.80...@affinityvision.com.au
Re: MIT discovered issue with gcc
On 25/11/2013 12:15 AM, Henrique de Moraes Holschuh wrote: Well, my best guess is that this is going to be considered upstream issues by the majority of the package maintainers, and thus they won't get much attention downstream (in Debian) until they start causing large headaches. That's my greatest worry, it will almost always be someone else's problem. When the problems extend right up to the kernel, it is a worry; if the programming practices that give these results are normal and desired though, the compiler needs to be *fixed* or a simpler fix might be just to recompile without letting the errant behaviour occur, but alas, from this thread (as you would expect), it isn't that simple. :( So, yes, users should be concerned (but not alarmed). Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52936a72.4060...@affinityvision.com.au
MIT discovered issue with gcc
Hi, I understand that Debian has a bunch of vulnerabilities as described in the following PDF. http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf Just a small quote: This paper presents the first systematic approach for reasoning about and detecting unstable code. We implement this approach in a static checker called Stack, and use it to show that unstable code is present in a wide range of systems software, including the Linux kernel and the Postgres database. We estimate that unstable code exists in 40% of the 8,575 Debian Wheezy packages that contain C/C++ code. We also show that compilers are increasingly taking advantage of undefined behavior for optimizations, leading to more vulnerabilities related to unstable code. This looks very serious indeed, but a quick search of Debian mailing lists didn't show anything being acknowledged for this issue should Debian users be concerned? -- Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52900522.9040...@affinityvision.com.au
Re: MIT discovered issue with gcc
Hi, The following link shows the issue in a nutshell: http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c [it refers to the PDF that I mentioned] -- Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52900637.1080...@affinityvision.com.au
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On 9/09/2013 2:18 AM, Volker Birk wrote: On Sun, Sep 08, 2013 at 12:55:05PM -0300, Henrique de Moraes Holschuh wrote: Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. Next problem: security is about trusting other people. If you don't trust Intel or AMD, better don't use their products. I see a lot of things which are destroyed now – it is not only the “cloud”. This game is over anyways. It's about the base we're all standing on. The US government and the NSA are eliminating that, and nothing less. If we cannot trust in the manufacturers of the CPUs, we don't have computers any more we can use. This is absolutely a problem, I have no doubt that the NSA has hooks in as well as requirements to hinder user security. This article [2], points to the Intel Secure Key technology [3] (in newer Intel CPUs). The first intro line of the Intel link says: Intel Secure Key, was previously code-named Bull Mountain Technology. The NYT article [0] mentions Bullrun as a program , that neatly fits with Bull Mountain Technology So, if we have a new enough [later I7?, 3rd gen or later] Intel CPU, then chances are that the random number generator will bring in issues that will interfere with the security of GPG when generating keys, due to NSA requirements. And here is a quote about /dev/random . (from another mailing list that I participate on): I'm glad Ted Ts'o also understands the need to avoid opaque instruction sets that can't be independently audited, and has resisted pressure from Intel engineers to allow /dev/random to rely solely on the RDRAND instruction. You can't trust the random number generator in Intel CPUs, the special function. If crypto key generation relies on proper random number generation, then crypto is busted ... just ask CryptoCat what happens when there is a flaw in random number generation [4], since fixed by the way. So, all in all, I can see how /any/ microcode update could be the result of NSA requirements and it throws a whole can of worms on trust, particularly with ANY business that is US based or has links to US based companies which may exert pressure to force issues. Furthermore, do we update microcode for older CPUs and potentially allow them to /own/ us too? Do we only use CPUs that pre-date this issue? There are loads of questions, what hope do we have? And this [5] is something that I'll probably end up using to harden my GPG keys. [0] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?_r=1; [1] http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide [2] http://blog.cryptographyengineering.com/2013/09/on-nsa.html [3] http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology [4] http://tobtu.com/decryptocat.php https://duckduckgo.com/?q=cryptocat%20random%20number%20issue (for more links) [5] http://gagravarr.livejournal.com/137173.html?nojs=1 (Creating a 8192 bit GPG key to replace my 1024 bit one) Cheers AndrewM signature.asc Description: OpenPGP digital signature
Re: Debian LTS?
Hi, Sythos wrote: On Wed, 05 Oct 2011 19:13:33 +0200 wer...@aloah-from-hell.de wrote: The major benefit of opensource software is the darwin effect, good software evolve quickly, bad software die, force a maintainer to work on a software for 2 years more than usual may mean force a unusefull work, *imho* 3 years are already too much for a lot of enviroments (like development) There are many whom won't spend a cent on something that is working, such as a small business with one internal server which doesn't host any external services (restricted ssh for support maybe, but that's all). Those are the kinds of businesses that will run XP as a server until the machine dies and not even bother with security updates. Some people shouldn't own computers ;-) And insofar as LTS is concerned, well -- what happens if you install a new server at year 3 or year 4, you're already well behind the 5 year cycle. I would like to see all major release having support for 5 years. And yes, I do see the problems with that too. But the long term support can concentrate on bug fixes only (security and product functionality). Don't get me wrong, but one of things I don't like about Debian is that there are possible unsupported packages from an earlier release that stay there with a rolling update. Those packages may be useful, it is a pity that they can't continue to be supported, but getting a package sponsor is the problem. Install a new system and you can't easily have that older package. Anyway, all this gets complicated. The greatest goal in my opinion, should be to support the security and stableness of every major release as long as possible, within reason. And I don't think that 30 months to 3 years is long enough; and this is certainly re-enforced by those seeking an LTS version. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8e6b56.2090...@affinityvision.com.au
Re: Grave apache dos possible through byterange requests
Hi,
Carlos Alberto Lopez Perez wrote:
You can use the following redirect as a temporally workaround:
# a2enmod rewrite
RewriteEngine On
RewriteCond %{HTTP:Range} bytes=0-.* [NC]
RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
Would that work for all websites of a Debian server if placed into a
file located in /etc/apache2/conf.d ?
Will other rewrites will be fine in the normal conf files for each website?
Thanks
--
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e54eaa3.4080...@affinityvision.com.au
Re: Upcoming Squeeze point release 6.0.2
Hi Adam, Adam D. Barratt wrote: That issue has been corrected, and the point release is being re-published this morning as 6.0.2.1. There are no changes in package content; the only difference from the original 6.0.2 (aside from versioning in Release files, etc.) is the fix to the Packages files. Then, shouldn't that be 6.0.2a just like which occurred previously to result in 6.0.1a to replace 6.0.1 -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0734db.1050...@affinityvision.com.au
Re: Question related to FDE (Full Disk Encryption) solution under Linux Debian Lenny
Jonas Andradas wrote: In particular, both mandos and mandos-client have Debian packages available. [1] http://www.fukt.bsnet.se/mandos That sounds interesting, but why not run the Mandos server ONLY when you are restarting machines. The Mandos server could be a tiny VM or even a boot from a USB thumb drive -- the USB could be locked away in a safe until required. A copy of the USB could be stored in a bank vault. The only time that the USB is needed is when you must restart a server or re-mount a file system protected by this scheme. No need to continually run a Mandos server anywhere. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3d5d22.2080...@affinityvision.com.au
Re: Question related to FDE (Full Disk Encryption) solution under Linux Debian Lenny
Hi Jonas, Jonas Andradas wrote: however, having to start up the Mandos server in order for the host to start-up could defeat the purpose of Mandos itself, which is supposed to allow servers to start up autonomously, without human intervention. Of course, you could always have your monitoring software detect the server failure or reboot and as an action, trigger the startup of a Mandos VM. In this case, however, the Mandos server probably would not be full-disk encrypted (otherwise, it would need human intervention to start or another Mandos-server running somewhere), but maybe it would be possible to come up with an interesting setup to achieve this. It also sounds like something that could be turned into a service, like DNS -- have two or more Mandos servers available for clients; same as DNS, have them on different networks and also different physical locations where possible. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3d7662.9050...@affinityvision.com.au
Re: Question related to FDE (Full Disk Encryption) solution under Linux Debian Lenny
Hi, Thomas Nguyen Van wrote: Correct me if I'm wrong but Mandos only works on a LAN according to the technical overview (http://wiki.fukt.bsnet.se/wiki/Mandos#Architectural_Overview). Just a LAN or can it be ANY routeable address, via the Internet? This assumes that the network connectivity is already operational. But how to deal with this when it's not the case: Our machine is an openvpn-gateway connected between our customer's infrastructure and our intranet. But, there is no dedicated line from our customer and us. So it goes through internet and our gateway is connected to internet directly with an ADSL card. So that the Mandos server should be somewhere in our intranet and the Mandos client will be installed on the machine. Therefore, it becomes a bit more difficult because I can't encrypt all of my hard drive because I need ADSL credential for authentication with the ISP in clear text. I prefer to let a dedicated machine do firewall / routing for me and to have any servers in the DMZ. The servers don't need to have any details about PPP login in this case. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3dad20.6060...@affinityvision.com.au
Re: exim4 router problems since 2 days / sucpicous process zinit is pstree
Thomas Krichel wrote: chattr -sia /bin/ps ; scp r...@nebka:/usr/bin/ps /usr/bin/ps ; sudo apt-get -y install --reinstall procps So, in effect, did you possibly give away your root password or pass phrase key for the netbka machine? I wouldn't be that trusting, you already know you were compromised -- best to re-install clean if you ask me. In the Windows world, my advice is the same, no matter how well you clean things, there is always the possibility that something nasty will remain undetected; it isn't worth that risk IMHO. Cheers -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0cbddd.2060...@affinityvision.com.au
Re: exim4 router problems since 2 days / sucpicous process zinit is pstree
Thomas Krichel wrote: Andrew McGlashan writes Thomas Krichel wrote: chattr -sia /bin/ps ; scp r...@nebka:/usr/bin/ps /usr/bin/ps ; sudo apt-get -y install --reinstall procps So, in effect, did you possibly give away your root password or pass phrase key for the netbka machine? Yup. After killing the dropbear process. Perhaps it would have been better to work from from a non-infected machine; do the scp of such files or better still just backup the data. nebka:# scp -p /usr/bin/ps r...@infected-machine:/usr/bin/ps and/or nebka:# scp -pr /saved-data-dir r...@infected-machine:/data-dir rsync might be an option too... Perhaps even use a live-cd or work in a chroot to offer as much protection as possible for the non-infected machine. You've also got to hope that scp or any other programs/binaries you rely on themselves aren't infected on the compromised machine in a way that might cause further issues. I wouldn't be that trusting, I wouldn't be either, but what is man to do who is not a security expert to do? you already know you were compromised -- best to re-install clean if you ask me. yeah, but I have no physical access to the infected box and must keep its data. I reinstalled all the packages. psutils was the one that got aptitude stymied. If you have no physical access, do you have a way to nuke and re-install? Is it VPS or similar? Something I've discovered as a really good feature of HP's iLO is the ability to mount an ISO from a local / trusted source and boot a machine remotely using the virtually mounted CD/DVD -- that gives you a whole new level of access without the need for actual physical access. You can work with a console remotely too in this case. Once it is running, you could install ssh server, set a password and use it in a more traditional way. Of course, it won't help if the machine doesn't have iLO or is a VPS itself -- but there might be similar methods with a VPS. Oh and HP's iLO might need an advanced license for virtual media to work, not sure about that yet. I picked up a nice DL380 G4 with the advanced iLO license already installed. Cheers -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0cc44e.7050...@affinityvision.com.au
Re: exim4 router problems since 2 days / sucpicous process zinit is pstree
Andrew McGlashan wrote: nebka:# scp -pr /saved-data-dir r...@infected-machine:/data-dir Umm, correction scp -pr r...@infected-machine:/data-dir /saved-data-dir Oh and HP's iLO might need an advanced license for virtual media to work, not sure about that yet. I picked up a nice DL380 G4 with the advanced iLO license already installed. Yep, the virtual media is an advanced license feature, just looked up the manuals (PDF search). Sure is handy though. Cheers -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0cc70b.70...@affinityvision.com.au
Re: Lenny version info
Ashley Taylor wrote: Sorry, this is the way Gmail handles replies. Simple answer use a proper email client. Google allows you to do IMAP with Thunderbird or other email clients. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d08bef1.7050...@affinityvision.com.au
Re: Lenny version info
Anh K. Huynh wrote: You may try cat /etc/debian_version Thank you, I'm sure that perfectly answers the OP's question exactly and very clearly. Cheers A. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d05e05f.10...@affinityvision.com.au
Re: Lenny version info
Chris Wadge wrote: PS: I've solved my problem. Thanks to those that actually helped. Besides all the noise, the version of Lenny can be directly relevant to the security of the installation ... and therefore it could technically and possibly correctly (don't care for the debate on this though) be sent to debian-security list Was it not Lenny 5.0.7 as determined by cat /etc/debian_version amongst other [possible] methods, then there would be a security issue, but read on However, the debian-users remains the most likely best avenue for such a question; the next question is how to upgrade and make the installation secure if the version is not 5.0.7 .. again, a better question for debian-user list I would presume. ;-) -- Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d06f385.8050...@affinityvision.com.au
Re: Lenny version info
Hi, Chris Bannister wrote: On Mon, Dec 13, 2010 at 03:05:45PM +1030, Ashvin Narayanan wrote: Thanks Jim/Michael for taking time to show me how to use Google instead of simply pointing me to debian-users. Naturally, I assume you would do a google first!!! Just think, in a few years time if someone googles your name, will they think you ignorant/lazy and not able to use a search engine? I don't understand why everyone thinks a personal attack is in order here??? The following from one of my own fully updated Debian servers is as follows: # cat /etc/issue Debian GNU/Linux 5.0 \n \l That doesn't tell me a great deal in itself -- should it also say Lenny ? I think it should, but I don't make those decisions; it certainly is debatable. The latest stable release today is 5.0.7 ... but that is the whole distro, not just which Linux do I have. What version of Linux well, the only simple answer is, see your kernel version from: # cat /proc/version Most of us know, fwiw, that Linux is just the kernel, with the distro counting for much more overall. The file /etc/issue may not exist on all Linux distros either. Of course there are other methods / tools and even further questions, I'm sure. Perhaps a look at /etc/apt/sources.list would be in order too, for some more answers. And being a Debian distro, some reading of man pages for dpkg as well. And yes, the query should have been sent to debian-users, but that doesn't mean a personal attack is warranted, does it? Do you want to drive Debian users away or encourage them to stay? Google has many answers, and some might be better searching: http://google.com/linux However, Google doesn't have all the answers, a polite response may have been a better outcome in this case and other somewhat considered trivial cases -- it was good enough to spend the time attacking a person, but not good enough to help with a real answer? Sure, some questions are too trivial and seem to be noise for noise sake, so just ignore them and let the person asking such questions consider again how to ask a good question or do some of their own ground work first. Whilst searching Google will give many answers, sometimes the answer simply lies within the machine in question itself and maybe even it's own dedicated mailing list users whom would like to help and promote their disto of choice, rather than dampen the spirits of an enquirer. As we say in AU, Fair go. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d05c8c1.5090...@affinityvision.com.au
broken updates just now clamav ....
Sending this via gmail because my server is broken now :( Setting up clamav-daemon (0.93~dfsg-volatile1) ... Installing new version of config file /etc/logcheck/ignore.d.paranoid/clamav-daemon ... Installing new version of config file /etc/init.d/clamav-daemon ... Starting ClamAV daemon: clamd LibClamAV Error: cli_loaddb(): No supported database files found in /var/lib/clamav ERROR: Not supported data format failed! This from clamav.log Fri May 30 17:21:05 2008 - SelfCheck: Database status OK. Fri May 30 18:24:54 2008 - SelfCheck: Database status OK. Fri May 30 18:28:50 2008 - Socket file removed. Fri May 30 18:28:50 2008 - Pid file removed. Fri May 30 18:28:50 2008 - --- Stopped at Fri May 30 18:28:50 2008 Fri May 30 18:29:05 2008 - +++ Started at Fri May 30 18:29:05 2008 Fri May 30 18:29:05 2008 - clamd daemon 0.93 (OS: linux-gnu, ARCH: i386, CPU: i486) Fri May 30 18:29:05 2008 - Log file size limit disabled. Fri May 30 18:29:05 2008 - Reading databases from /var/lib/clamav Fri May 30 18:29:05 2008 - Not loading PUA signatures. Fri May 30 18:29:05 2008 - ERROR: Not supported data format And this from freshclam.log -- Received signal: wake up ClamAV update process started at Fri May 30 18:18:33 2008 WARNING: Your ClamAV installation is OUTDATED! WARNING: Local version: 0.92.1 Recommended version: 0.93 DON'T PANIC! Read http://www.clamav.net/support/faq main.inc is up to date (version: 46, sigs: 231834, f-level: 26, builder: sven) daily.inc is up to date (version: 7287, sigs: 70923, f-level: 26, builder: neo) -- -- freshclam daemon 0.93 (OS: linux-gnu, ARCH: i386, CPU: i486) ClamAV update process started at Fri May 30 18:29:02 2008 Downloading main.cvd [100%] main.cvd updated (version: 46, sigs: 231834, f-level: 26, builder: sven) Downloading daily.cvd [100%] daily.cvd updated (version: 7287, sigs: 70923, f-level: 26, builder: neo) Database updated (302757 signatures) from db.local.clamav.net (IP: 116.240.207.20) -- Received signal: re-opening log file ClamAV update process started at Fri May 30 18:31:39 2008 main.cvd is up to date (version: 46, sigs: 231834, f-level: 26, builder: sven) daily.cvd is up to date (version: 7287, sigs: 70923, f-level: 26, builder: neo) -- Kind Regards AndrewM Andrew McGlashan Affinity Vision Australia Pty Ltd
Re: clamav.* package versions (etch)
Hi, Martin Zobel-Helas wrote: Is is already escalated, and we are working on that problem getting fixed. clamav will be available in a few minutes. Setting up clamav-daemon (0.93~dfsg-volatile1) ... Installing new version of config file /etc/logcheck/ignore.d.paranoid/clamav-daemon ... Installing new version of config file /etc/init.d/clamav-daemon ... Starting ClamAV daemon: clamd LibClamAV Error: cli_loaddb(): No supported database files found in /var/lib/clamav ERROR: Not supported data format failed! Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA/DSS keys and DSA 1576-1/CVE-2008-0166.
Hi, Mario 'BitKoenig' Holbe wrote: Kurt Roeckx [EMAIL PROTECTED] wrote: So my question is, does either the ssh client or server use openssl to generate the random number used to sign? Yes, they both do. ssh-dss.c:ssh_dss_sign() calls openssh's DSA_do_sign() which finally goes down to ssleay_rand_add() (via dsa_sign_setup()-BN_rand_range()- RAND_add()-RAND_SSLeay()). And ssh_dss_sign(), in turn, is used via key_sign() in the ssh server as well as the client. Okay, if we updated (on stable): openssl_0.9.8c-4etch3_i386.deb libssl0.9.8_0.9.8c-4etch3_i386.deb Then re-generated all keys and certificates. Later we get these updates: openssh-blacklist_0.1.1_all.deb ssh_1%3a4.3p2-9etch1_all.deb openssh-server_1%3a4.3p2-9etch1_i386.deb openssh-client_1%3a4.3p2-9etch1_i386.deb So, do we need to re-generate keys and certs again now or will they be fine? The tests against the certs seems to be fine, but I want to be sure that the later updates were not required for the re-generation to be worthwhile. Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1572-1] New php5 packages fix several vulnerabilities
Hi, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : Does anyone have the same problem ? Ok, it seems there is a problem with : libphp5.so (libapache2-mod-php5) I replaced the file with an older one and it works. I backed up the file just in case and did the upgrade without problems. still have the backup file, but it doesn't seem to be required. Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ClamAV concerns
Hi Yanosz, Jan Luehr wrote: we're using ClamAV on our mail server for scanning incomming mail server-side on Etch. However, looking back at ClamAV's history (DSA-1320-1, DSA-1366-1, DSA-1435-1, DSA-1479, DSA-1549) makes me feel a little bit uneasy. To be honest, ClamAV had more remote exploitable holes than all of other public reachable services together. Therefore imho it's difficult to say, whether ClamAV protects our network or puts our server at risk. First off, one of the major benefits of ClamAV is that _if_ there is any vulnerability found in particular modules, then a machine that actively uses freshclam will very quickly close off the module that exploits such vulnerability until it can be more properly addressed. Furthermore the security advisories don't seem to take the above behaviour into account and they are often misleading in themselves... I believe the same can be often said about other 'vulnerable' products, that is, they are not as vulnerable as they seem unless updates are not installed regularly. What Do you think about this? Do you know reasons for ClamAV's unusual high number of bugs? Would you abandon ClamAV for server side mail scanning in favor of other scanners? I would not abandon ClamAV. At this time I don't know of any other AV scanner that competes well with ClamAV on a mail server that can potentially host any number of domains and mail boxes. Too many products charge by the domain or by the number of mail boxes stick with ClamAV. The support with ClamAV is outstanding from my experience and what I see on their mailling lists. Keep smiling ;) Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox on testing hijacked by http://www.megago.com/l/?
Pawel Krzywicki wrote: edit-preferences-main-home page -choose one :) save and that's all Tools-options [general tab] - home page - locations.. Or better still open a bunch of pages that you like to visit regularly and make the set 'use current pages'... - the caveat to this is that the tabs should all be of the one wndow and not encompass multiple windows Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP 1300 85 3804 Mobile: 04 2574 1827 Fax: 03 8790 1224 Affinity Vision Australia Pty Ltd www.affinityvision.com.au www.affinityvision.net/adsl/ In Case of Emergency -- http://www.affinityvision.com.au/ice.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Collective memory query
Does this resemble what you want? http://www.cs.rit.edu/~hpb/Man/_Man_Local_html/html1/srwin.1.html Regards AndrewM Andrew McGlashan ADSL, Dialup, Satellite, ISDN and other enquiries: 1300 85 3804 Mobile: 04 2574 1827 Fax: 03 8790 1224 Affinity Vision Australia Pty Ltd www.affinityvision.com.au www.affinityvision.net/adsl/ - Original Message - From: Dale Amon [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Monday, September 27, 2004 9:48 PM Subject: [OT] Collective memory query
Re: [OT] Collective memory query
Sorry wrong link... I didn't look closely at it. Ughh. Andrew McGlashan wrote: Does this resemble what you want? http://www.cs.rit.edu/~hpb/Man/_Man_Local_html/html1/srwin.1.html Regards AndrewM Andrew McGlashan ADSL, Dialup, Satellite, ISDN and other enquiries: 1300 85 3804 Mobile: 04 2574 1827 Fax: 03 8790 1224 Affinity Vision Australia Pty Ltd www.affinityvision.com.au www.affinityvision.net/adsl/ - Original Message - From: Dale Amon [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Monday, September 27, 2004 9:48 PM Subject: [OT] Collective memory query AndrewM Andrew McGlashan ADSL, Dialup, Satellite, ISDN and other enquiries: 1300 85 3804 Mobile: 04 2574 1827 Fax: 03 8790 1224 Affinity Vision Australia Pty Ltd www.affinityvision.com.au www.affinityvision.net/adsl/
Re: [OT] Collective memory query
Try again: http://packages.debian.org/testing/utils/rpl Intelligent recursive search/replace utility Regards AndrewM Andrew McGlashan ADSL, Dialup, Satellite, ISDN and other enquiries: 1300 85 3804 Mobile: 04 2574 1827 Fax: 03 8790 1224 Affinity Vision Australia Pty Ltd www.affinityvision.com.au www.affinityvision.net/adsl/
