Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit

2018-01-03 Thread Vincent Deffontaines

Greetings,

And happy new year.

This is hitting all of us soon.
In short : a huge (and long lasting) hardware bug, present in about all 
Intel CPUs that have been sold for the last 10 years.
It is not fixable by microcode, and requires ugly patching from the 
kernel layer. Other OSes such as Microsoft are concerned as well.


Nice overview of the thing :
https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos

More detail :
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

Linus' patch :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf


Vincent Deffontaines



Re: libapache2-mod-security2 error message

2017-01-23 Thread Vincent Deffontaines

Le 2017-01-23 03:26, Tea Wrex a écrit :

I'm getting this error message and I don't know what to do to remedy
it.
Note: It was working fine the other day and I have not modified
anything since it was working

This is from the Apache error log.

[Sun Jan 22 17:46:49.561357 2017] [mpm_prefork:notice] [pid 27576]
AH00169: caught SIGTERM, shutting down

[Sun Jan 22 17:46:51.001201 2017] [:notice] [pid 27640] ModSecurity
for Apache/2.8.0 (http://www.modsecurity.org/) configured.

[Sun Jan 22 17:46:51.001315 2017] [:notice] [pid 27640] ModSecurity:
APR compiled version="1.5.1"; loaded version="1.5.1"

[Sun Jan 22 17:46:51.001321 2017] [:notice] [pid 27640] ModSecurity:
PCRE compiled version="8.35 "; loaded version="8.35 2014-04-04"

[Sun Jan 22 17:46:51.001330 2017] [:notice] [pid 27640] ModSecurity:
LUA compiled version="Lua 5.1"

[Sun Jan 22 17:46:51.001333 2017] [:notice] [pid 27640] ModSecurity:
LIBXML compiled version="2.9.1"

[Sun Jan 22 17:46:51.001389 2017] [:notice] [pid 27640] ModSecurity:
StatusEngine call: "2.8.0,Apache,1.5.1/1.5.1,8.35/8.35 2014-04-04,Lua
5
.1,2.9.1,04"

[SUN JAN 22 17:46:51.179137 2017] [:NOTICE] [PID 27640] MODSECURITY:
STATUSENGINE CALL FAILED. QUERY:
GIXDQLRQFRAXAYLDNBSSYMJOGUXDCLZR.FY2S4
MJMHAXDGNJPHAXDGNJAGIYDCNBN.GA2C2MBUFRGHKYJAGUXDCLBSFY4S4MJM.GA2A.1485136010.status.modsecurity.org
[1]
[Sun Jan 22 17:46:52.005083 2017] [mpm_prefork:notice] [pid 27641]
AH00163: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming
nor
mal operations

[Sun Jan 22 17:46:52.005129 2017] [core:notice] [pid 27641] AH00094:
Command line: '/usr/sbin/apache2'


THIS IS THE LOG ENTRIES FROM WHEN IT WAS WORKING FINE:

[Sat Jan 21 02:38:42.900275 2017] [mpm_prefork:notice] [pid 31795]
AH00169: caught SIGTERM, shutting down

[Sat Jan 21 02:42:22.000351 2017] [:notice] [pid 18967] ModSecurity
for Apache/2.8.0 (http://www.modsecurity.org/) configured.

[Sat Jan 21 02:42:22.000483 2017] [:notice] [pid 18967] ModSecurity:
APR compiled version="1.5.1"; loaded version="1.5.1"

[Sat Jan 21 02:42:22.000490 2017] [:notice] [pid 18967] ModSecurity:
PCRE compiled version="8.35 "; loaded version="8.35 2014-04-04"

[Sat Jan 21 02:42:22.000500 2017] [:notice] [pid 18967] ModSecurity:
LUA compiled version="Lua 5.1"

[Sat Jan 21 02:42:22.000502 2017] [:notice] [pid 18967] ModSecurity:
LIBXML compiled version="2.9.1"

[Sat Jan 21 02:42:22.000549 2017] [:notice] [pid 18967] ModSecurity:
StatusEngine call: "2.8.0,Apache,1.5.1/1.5.1,8.35/8.35 2014-04-04,Lua
5
.1,2.9.1,04"

[Sat Jan 21 02:42:23.303215 2017] [:notice] [pid 18967] ModSecurity:
StatusEngine call successfully sent. For more information visit:
http:/
/status.modsecurity.org/ [2]


[Sat Jan 21 02:42:24.003412 2017] [mpm_prefork:notice] [pid 18969]
AH00163: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming
nor
mal operations

[Sat Jan 21 02:42:24.004524 2017] [core:notice] [pid 18969] AH00094:
Command line: '/usr/sbin/apache2'



Links:
--
[1]
http://MJMHAXDGNJPHAXDGNJAGIYDCNBN.GA2C2MBUFRGHKYJAGUXDCLBSFY4S4MJM.GA2A.1485136010.status.modsecurity.org
[2] http://status.modsecurity.org/



Hi,

Have you tried setting
SecStatusEngine off ?
It seems your apache2 fails at notifying status.modsecurity.org online, 
as it is starting.
See 
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecStatusEngine 
for more details.


Vincent


--
What is it you need, that makes your heart beat ?
Do you really know, cause it doesn't show.
New Order - Round & round



Re: Is this a hacking attempt?

2015-01-20 Thread Vincent Deffontaines

Le 2015-01-20 12:40, Marko Randjelovic a écrit :

I was running Wheezy Iceweasel with vanilla 3.14 kernel with grsec. I
tried to play video on YouTube with gnash plugin but Iceweasel 
crashed

with alike messages

execution attempt in ...
Terminating task /usr/lib/iceweasel/iceweasel

Full log can be found on http://paste.lisp.org/+343V




Hi,


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.


As a side note, youtube supports HTML5, and if your browser had no 
flash support at all but HTML5 support, then you, your grsec kernel, and 
all kittens in the world could just be delighted and still have youtube 
content played fine.


Cheers,

Vincent



--
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/01628a71ffdcbbaab3e6816de3861...@raceme.org



Re: Root login

2008-09-08 Thread Vincent Deffontaines

Marek Kubica a écrit :

On Thu, 4 Sep 2008 13:25:13 +0100
Paweł Krzywicki [EMAIL PROTECTED] wrote:


the solution was as Cerbelle said. Login as a normal user and do
sudo ( or you can activate root login from the login menu; but i
personally consider it really dangerous!)
I am wondering why this is dangerous? 
If your password is seen as strong FaG34#fCFD12drtfdg something

like this for example why this is dangerous?


The point is, that 1) not too many people use strong passwords 2)
having root access allowed makes it harder to break in, since the
username is known as it is always root. User-accounts might be named
pawel, pawelk, krzywicki or be completely unknown for the attacker.



Greetings,

Even though this principle is true, it seems to me it is not in 
application on every system.


Try to login on any Lenny box console with an invalid account.
You will get Incorrect login without being prompted for a password at all.
I tend to consider this as a quite bad bug, but it seems it has been so 
for a while in Lenny, and even in upstream PAM.


Vincent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver

2008-08-13 Thread Vincent Deffontaines

Moritz Muehlenhoff a écrit :
 Hideki Yamane  wrote:
 The 2.6.24
 kernel available since the last etch point release offers some
 protection as well.

  Umm? This is NEW information for me. Could you give me any references?
  (certainly if you can disclosure. It is a sensitive issue.)

 The Linux kernel implements UDP source port randomisation since 2.6.24:

And the Linux kernel (Netfilter) implements NAT source port randomization
since 2.6.21, which can make it a conveninent way to protect your natted
hosts without any patching.

See http://software.inl.fr/trac/wiki/contribs/RandomSkype for details.

Vincent


-- 
On sait qu'une cité va devenir grande quand on y voit les anciens planter
des arbres, alors qu'ils savent qu'ils ne profiteront jamais de leur
ombre.

Proverbe Grec


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Sarge, Bind9 (9.2.4-1sarge3) and DNS cache poisoning

2008-07-18 Thread Vincent Deffontaines

John Elliot a écrit :

Hi,
 
We have a couple of Sarge servers running bind9(9.2.4-1sarge3) that 
appear to be vulnerable to the DNS cache poisoning issue(Looks like port 
randomization was only introduced in bind9.3?) - As the servers cannot 
be upgraded at this time to etch, what is the recommended course of 
action? Backports and upgrade to 9.3?


Greetings,

One solution is to let another device do the port randomization, to 
protect your DNS clients.


If you run a Netfilter NAT firewall, you can use the source port NAT 
randomization feature of Netfilter. This feature is available in Linux 
vanilla kernel since 2.6.21.1


See http://software.inl.fr//trac/wiki/contribs/RandomSkype

Vincent Deffontaines


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Why not have firewall rules by default?

2008-01-23 Thread Vincent Deffontaines

Michael Loftis wrote:
[snip]
It's better to leave the service disabled, or even better, completely 
uninstalled from a security standpoint, and from a DoS standpoint as 
well. The Linux kernel isn't very efficient at processing firewall 
rules.  Newer kernels might be though (I honestly haven't looked as 
deeply into this in late 2.6 as i did/do in 2.4...2.4 processes 
firewall rules strictly step by step)
The processing of Netfilter rules has not fundamentally changed from 2.4 
to 2.6.
However, there is a way to load rules in a monilithic way, by using 
iptables-restore, in place
of calling iptables multiple times. (IIRC, at some point in the past, 
debian used that to save

rules at system shutdown and reload them at boot, but I may be wrong).

Vincent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: INFECTED (PORTS: 600)

2006-05-19 Thread Vincent Deffontaines
Michael Loftis wrote:


 --On May 18, 2006 9:17:09 AM -0400 Morgan Walker [EMAIL PROTECTED] wrote:



 Hey guys,



 Just new to this mailing list, hope you guys can help me out. I was
 testing out the chkrootkit package on one of my debian boxes. After
 running 'chkrootkit --q' I received the following output:

 Use lsof and ps to find out who's running that proc and where from. If
 root isn't running it then someone has a hacked binary that's trying
 to hide, if root is, and lsof indicates it's not /sbin/rpc.statd then
 you're owned. It's kind of unusual for statd to show up on such a low
 port but not totally unheard of.


Indeed, root has to be running it. It looks like a privileged port to me.

Vincent Deffontaines


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



[OT] Trojan/[spy/ad]ware and thawte.com

2004-06-01 Thread Vincent Deffontaines
This is the 2nd occurence of strange entries on my proxy logs, within a
few days (comments below):

***
10* - - [28/May/2004:14:09:17 +0200] GET
http://delivery.inet-traffic.com/inetdl.exe HTTP/1.0 200 247544
TCP_REFRESH_HIT:DIRECT

10* - - [28/May/2004:14:09:19 +0200] GET
http://crl.thawte.com/ThawteServerCA.crl HTTP/1.0 200 243691
TCP_CLIENT_REFRESH_MISS:DIRECT

***
And from another workstation's IP
***

10* - - [25/May/2004:16:42:35 +0200] GET
http://www.mt-download.com/MediaTicketsInstaller.cab HTTP/1.0 200 78402
TCP_MISS:DIRECT

10* - - [25/May/2004:16:42:36 +0200] GET
http://crl.thawte.com/ThawtePremiumServerCA.crl HTTP/1.0 200 852
TCP_CLIENT_REFRESH_MISS:DIRECT

10* - - [25/May/2004:16:42:36 +0200] GET
http://crl.thawte.com/ThawteCodeSigningCA.crl HTTP/1.0 200 8613
TCP_CLIENT_REFRESH_MISS:DIRECT

***

Here are questions I am wondering about :
1) What are those .crl files used for? Are they used by [spy/ad]wares for
some reason I ignore? Maybe they could be used to corrupt actual
browser's certs? This would be serious... Say some spyware changes certs
of banks, and modifies [\/etc\/hosts/lmosts]... Or maybe they are used for
something else I am not thinking of... I did not see HTTPS traffic (no
CONNECT) in the near future of these events in the logs.

2) I cannot believe this is a coincidence, as it has occured twice within
a few days. The [spy/ad]ware download and the cert retrieval definetely
seem related. Has anyone noticed the same behaviour? URLs on top are real,
and downloading and testing those files can easily be tested.

I thought I'd post these informations on this list, in case others have
noticed stuff.

Vincent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



[OT] Trojan/[spy/ad]ware and thawte.com

2004-06-01 Thread Vincent Deffontaines
This is the 2nd occurence of strange entries on my proxy logs, within a
few days (comments below):

***
10* - - [28/May/2004:14:09:17 +0200] GET
http://delivery.inet-traffic.com/inetdl.exe HTTP/1.0 200 247544
TCP_REFRESH_HIT:DIRECT

10* - - [28/May/2004:14:09:19 +0200] GET
http://crl.thawte.com/ThawteServerCA.crl HTTP/1.0 200 243691
TCP_CLIENT_REFRESH_MISS:DIRECT

***
And from another workstation's IP
***

10* - - [25/May/2004:16:42:35 +0200] GET
http://www.mt-download.com/MediaTicketsInstaller.cab HTTP/1.0 200 78402
TCP_MISS:DIRECT

10* - - [25/May/2004:16:42:36 +0200] GET
http://crl.thawte.com/ThawtePremiumServerCA.crl HTTP/1.0 200 852
TCP_CLIENT_REFRESH_MISS:DIRECT

10* - - [25/May/2004:16:42:36 +0200] GET
http://crl.thawte.com/ThawteCodeSigningCA.crl HTTP/1.0 200 8613
TCP_CLIENT_REFRESH_MISS:DIRECT

***

Here are questions I am wondering about :
1) What are those .crl files used for? Are they used by [spy/ad]wares for
some reason I ignore? Maybe they could be used to corrupt actual
browser's certs? This would be serious... Say some spyware changes certs
of banks, and modifies [\/etc\/hosts/lmosts]... Or maybe they are used for
something else I am not thinking of... I did not see HTTPS traffic (no
CONNECT) in the near future of these events in the logs.

2) I cannot believe this is a coincidence, as it has occured twice within
a few days. The [spy/ad]ware download and the cert retrieval definetely
seem related. Has anyone noticed the same behaviour? URLs on top are real,
and downloading and testing those files can easily be tested.

I thought I'd post these informations on this list, in case others have
noticed stuff.

Vincent



Re: Squid proxy help

2004-04-23 Thread Vincent Deffontaines
Craig Schneider a dit :
 Hi Guys

 I was just wondering if you know how I could possibly setup squid so
 that it will accept connections from the internet and filter before they
 hit a IIS6 hosted intranet.

 Any ideas at this point would be welcome.

 Thanks
 Craig




Squid has quite nice docs that explain that kind of reverse-proxy setup.
You can also consider using Apache with mod_proxy, and possibly mod_security

Vincent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Squid proxy help

2004-04-23 Thread Vincent Deffontaines
Craig Schneider a dit :
 Hi Guys

 I was just wondering if you know how I could possibly setup squid so
 that it will accept connections from the internet and filter before they
 hit a IIS6 hosted intranet.

 Any ideas at this point would be welcome.

 Thanks
 Craig




Squid has quite nice docs that explain that kind of reverse-proxy setup.
You can also consider using Apache with mod_proxy, and possibly mod_security

Vincent



Re: apache segmentation fault

2004-04-16 Thread Vincent Deffontaines
Robert Velter a dit :
 Hello all,

 there seems to be a new apache vulnerability. Following error messages
 occure many times in my error.log:

[...]
 System is woody with all security updates applied.
 Any hints or tips how to track down the attack?


A good start might be :

LogLevel debug

in your httpd.conf

Vincent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: apache segmentation fault

2004-04-16 Thread Vincent Deffontaines
Robert Velter a dit :
 Hello all,

 there seems to be a new apache vulnerability. Following error messages
 occure many times in my error.log:

[...]
 System is woody with all security updates applied.
 Any hints or tips how to track down the attack?


A good start might be :

LogLevel debug

in your httpd.conf

Vincent