Re: Is this a hacking attempt?
On Tue, Jan 20, 2015 at 07:42:03PM +0100, Marko Randjelovic wrote: My understanding from the grsec logs you pasted is that gnash tried to allocate more memory than your RLIMIT-MEMLOCK limit (65536), and this is the reason why gnash crashed. I wouldn't hint this is sufficient to conclude in hacking. Flash is known well enough for eating a lot of memory at times. I would suggest either to try playing similar flash from trusted sources (good luck finding them though, maybe @adobe.com - One might also believe youtube.com is a trusted source ) and see if the plugin crashes on them too ; or maybe to raise limit progressively to see where it is accepted. I tried to raise limit some time ago, but I was unsuccessful. Do you know how to do it? I believe that man 5 limits.conf helps. signature.asc Description: Digital signature
Re: about bash and Debian Lenny
On Wed, Oct 01, 2014 at 02:28:17PM +0300, Nikolay Hristov wrote: Hello there, I know that this is outdated debian release and it is in the archives but I still have 6 servers running Lenny and I don't want to upgrade them to newer versions for several reasons. Any chance that we will get official debian package for Lenny? I'm sure that I'm not the only one with such problem. I don't want to use deb packages from different sources because I cannot trust them. Shellshock has such big impact on the internet so please give us Lenny package. You're doing this the wrong way - as others have already said, upgrade your server to a supported release. That said... have a look at this thread on oss-security for some suggestions of easy-to-understand binary patches that will remove the vulnerable feature: http://www.openwall.com/lists/oss-security/2014/09/29/1 http://www.openwall.com/lists/oss-security/2014/09/29/6 signature.asc Description: Digital signature
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote: But again, that's only half the story. When you send a kernel image encrypted, they have the plaintext and the crypt, and the thing is large and hard. This is the kind of data that can be used to completely break an entire encryption algorithm. When you say break an entire encryption algorithm, do you mean find the key or really break the whole algorithm? If you mean break the whole algorithm and gain the ability to convert ciphertexts to plaintexts no matter what key was used, please consider that they could just encrypt a lot of data with random keys themselves instead of collecting it from the internet. If you mean find the key: So what? You're talking about session keys used in the TLS connection, right? Even if there was the kind of attack you're thinking about, it would only allow an attacker to gain access to the connection that he would be able to MITM anyway without the TLS layer. signature.asc Description: Digital signature
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network Heh. Because SSL/TLS libraries are so impenetrable and secure? :D signature.asc Description: Digital signature
http://lintian.debian.org/tags/setuid-binary.html is incomplete?
I thought that http://lintian.debian.org/tags/setuid-binary.html was a list of all setuid binaries in debian... but apparently, that's not correct? $ ls -l /usr/sbin/uuidd -rwsr-sr-x 1 libuuid libuuid 18840 Dez 11 2012 /usr/sbin/uuidd Doesn't show up on that list... what decides whether a binary gets flagged for being setuid or not? signature.asc Description: Digital signature
Re: MIT discovered issue with gcc
On Sat, Nov 23, 2013 at 08:14:34AM -0500, Brad Alexander wrote: Any program at a level not very much above Hello World in the language of your choice is likely to have bugs. Isn't that a bit extreme? I think that a good programmer who seriously tries to code carefully should be able to implement something like an FTP server with 90% certainty that there are no bugs. Not a complicated one with a ton of features, but a simple one should IMO be doable. signature.asc Description: Digital signature
Re: How secure is an installation with with no non-free packages?
On Thu, Sep 12, 2013 at 05:01:09PM -0500, Jordon Bedwell wrote: On Thu, Sep 12, 2013 at 5:01 PM, Jonathan Perry-Houts jperryho...@gmail.com wrote: I can't speak to those packages specifically but I think the answer you'll get from most people, especially in this community, is that non-free software is inherently insecure because you can't know exactly what it is doing. Thus, a fully free system such as Debian with only main enabled or Trisquel or so is, in principle, more trustworthy than any system running non-free code. That said, free code can of course have bugs and security holes too. It's probably less likely, with a community of thousands auditing it versus a closed group of developers, but it happens. This falls on the assumption that people actually audit the open source software they use, which most of the time is not the case because they have the same mentality you imply you have: with thousands auditing it, why should I? it must be secure... by that logic with millions auditing Android we shouldn't have had the recently huge crypto issue in Android right? You know, the one that slipped by for years. We shouldn't have had several other bugs that were years unnoticed in other software. Exactly. There's a bunch of simple-to-spot mistakes in open source software because nobody actually reads the source. Android has/had a bunch of such mistakes for quite a while: Reuse of IVs in a block cipher, simple filesystem races, missing input sanitation, missing delimiters... a lot of this is really simple stuff that anyone reading the code should be able to spot. Often, coders who don't have a lot of experience with security just write their code and maybe add a comment TODO check the security of this, I have no idea about it. Or I copy-pasted this security check, but I'm not really sure about how well-written it is. And then that comment usually stays forever. signature.asc Description: Digital signature
Re: Compromising Debian Repositories
On Sun, Aug 04, 2013 at 10:51:08AM +0200, Volker Birk wrote: Now I'm surprised ;-) I think, this is not a matter of security of checksums here. Of course, only a digital signature will do, or at least a MAC. Huh, what? Aren't MACs always symmetric? How do MACs fit in here? signature.asc Description: Digital signature
