Took me ages of fucking around to get bitlbee to compile with full RELRO.
In the end I had to hack the makefile.
At line 182 (the line where it gets linked) I had to add the following:
180 $(OUTFILE): $(objects) $(subdirs) 181 @echo '*' Linking $(OUTFILE) 182 @$(CC) $(objects) $(subdirobjs) *-march=native -O2 -fstack-protector-all -fpic -pipe -Wl,-z,relro,-z,now* -o $(OUTFILE) $(LDFLAGS_BITLBEE) $(LFLAGS) $(EFLAGS)
Vanilla Kernel
timh@Jumphost-Lab:~$ paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org> Released under the GNU Public Licence version 2 or later
Writing output to /home/timh/paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org> Released under the GNU Public Licence version 2 or later
Mode: Blackhat
Linux Jumphost-Lab 3.2.0-29-generic 46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomisation test : 9 bits (guessed)
Heap randomisation test (ET_EXEC) : 14 bits (guessed)
Heap randomisation test (PIE) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 8 bits (guessed)
Shared library randomisation test : 10 bits (guessed)
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Killed
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Killed
Grsecurity/PaX hardened kernel
Grsecurity Enabled Kernel
tim@beaker ~> paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org> Released under the GNU Public Licence version 2 or later
Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org> Released under the GNU Public Licence version 2 or later
Mode: blackhat
Linux beaker 3.6.8-grsec 1 SMP Wed Nov 28 09:30:28 NZDT 2012 i686 GNU/Linux
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 18 bits (guessed)
Heap randomisation test (ET_EXEC) : 22 bits (guessed)
Heap randomisation test (ET_DYN) : 24 bits (guessed)
Main executable randomisation (ET_EXEC) : 18 bits (guessed)
Main executable randomisation (ET_DYN) : 18 bits (guessed)
Shared library randomisation test : 18 bits (guessed)
Stack randomisation test (SEGMEXEC) : 24 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed
To be clear – I’m not trying to pick on anyone here. It’s just an amazing example of the confusion around UFB.
[24/10 10:44] <USER> @NZ_ISP can you please tell me the CIR on 100/50 business fibre?
[24/10 11:10] <@NZ_ISP> @USER My understanding is that it’s 10Mbps down, 2.5Mbps up (that’s for your plan). ^CP
[24/10 11:12] <@USER> @NZ_ISP OK. I think the support team are using that as an excuse. Hitting a wall at 35mbit, but they’re saying that’s OK.
[24/10 11:19] <@NZ_ISP> @USER That’s obviously well above CIR, but we want to make sure you’re getting as fast a speed as possible too. ^CP
[24/10 11:20] <@USER> @NZ_ISP I can’t break 35mbit with multiple streams from multiple fast NZ servers. There’s definitely an issue there.
[24/10 11:26] <@NZ_ISP> @USER I’m only passing on what our engineers have checked out – like I said, I’m having them check it again. ^CP
[24/10 11:28] <@USER> @NZ_ISP Thanks. I’ve emailed prem support again with more pretty pictures.
[24/10 15:24] <@kiwibrew> @USER if multiple streams saturate a connection, it’s a TCP tuning / receive window issue, not the circuit @stevebiddle @NZ_ISP
[24/10 15:29] <@USER> @kiwibrew Tell me more. Anything I can adjust at my end to enhance this?
[24/10 15:29] <@USER> @kiwibrew Err, it’s upload that’s not going as fast as it should too, btw.
[24/10 15:33] <@NZ_ISP> @USER The ticket is in a closed state so yes, you’ll continue to get those messages if you keep sending emails. I’m having them check…
[24/10 15:33] <@NZ_ISP> @USER …into it again though. ^CP
[24/10 15:34] <@USER> @NZ_ISP I think we’re at a stalemate anyway. I maintain 70% of advertised speed isn’t good enough. You maintain that you only promised me 2.5
[24/10 15:34] <@USER> @NZ_ISP As a side note the ONLY speed mentioned on the contract I signed was the 100/50. Hope you’ve got proper UFB contracts by now?
[24/10 15:36] <@NZ_ISP> @USER So would you like me to leave this ticket closed then? ^CP
[24/10 15:37] <@USER> @NZ_ISP You’re aware your customer is unhappy with the service you’re providing. Up to you if you re-open or leave it.
[24/10 15:38] <@kiwibrew> @USER Perry has some good resources here: http://wand.net.nz/~perry/max_download.php Also check http://nzbt.org.mz for limiting factors
[24/10 15:42] <@NZ_ISP> @USER Just had a chat with the team and they’ve let me know that the speeds are at an acceptable level for us and Chorus. You’re more…
[24/10 15:42] <@NZ_ISP> @USER …than welcome to have a chat with your account manager if you have any more concerns. ^CP
From the 10.4R10 release notes:
http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/release-notes/10.4/index.html
A service technician brushed against the front panel of a MX RE card, and the RE powered down. Resulted in outages of customer networks. [PR/703076: This issue has been resolved.]
Sadly they have updated the document.
Everyone’s got a comment about Fyx!
Here’s mine:
My analogy is that it’s like you all work in the pizza business. And you’re all discussing a rival pizza company because they’ve put a blinking LED on their pizza.
Sure, you can’t eat it. Or maybe you can? But maybe for a few weeks before everyone goes “You can’t eat LEDs, it’s not legal!!!”
So you all go on and on and on about the flashing LED on the pizza. Is it legal? Is it not? What happens if you EAT the LED? Will you have to be rushed to hospital? Will you be OK? OMFG!!!! OMG!?!?! Is it LEGAL to put an LED ON A PIZZA? PULL IT OFF!! But what if I can’t pull it off? Will I get sued? LOOK! LOOK AT IT FLASH!
They’re selling pizza. But you’re all OMFG about the flashing LED that may, or may not, come with the pizza. You’ve told all your family. Your friends. You’ve got just the best and smartest opinion about the legality of selling a flashing LED and you’ve told everyone you know about it.
And now, horror of horrors, you’ve found out the pizza DOES NOT come with a flashing LED. That’s it. They’ve officially called it. No more flashing LEDs.
Now you’re left with a normal, boring pizza. One you’ve not even tried but you know know you probably hate it.
Oh and there’s one marketing company behind it all that can’t stop laughing.