Re: make build crashing

2007-03-21 Thread Olivier Meyer

On 3/21/07, Greg Thomas <[EMAIL PROTECTED]> wrote:

On 3/21/07, Open Phugu <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Bray Mailloux <[EMAIL PROTECTED]> wrote:
> > I am updating my 4.0 system to the latest ~stable build and each time my
> > "make build" is crashing. What information should I post in order to
> > insure maximum clarity with the problem?
> >
> >
> Post the exact command, the output of the ``make build'', the output
> of ``uname -a''.

And at least summarize the steps you took before the above info.

I'll take a WAG and say you have bad RAM.

If you get something of the sort:
``gcc: Internal compiler error: program cc1 got fatal signal 11'',
you either have discovered an Internal Compiler error in gcc,
or you have bad RAM.
see http://www.bitwizard.nl/sig11/ for the bad-ram scenario



Re: 202 days Uptime in OpenBSD 3.6

2007-01-15 Thread Olivier Meyer

What really matters is the security of the applications you are
running(httpd, sshd, sendmail,...). If you keep those up to date, the
kernel really does not matter. If you look at
http://openbsd.org/security.html, most of the "openbsd" bugs really
are in openssh, the c library, or are a local privilege escalation
attack that cannot be exploited remotely.

On 1/15/07, Karl R. Balsmeier <[EMAIL PROTECTED]> wrote:

Joachim Schipper wrote:

>On Mon, Jan 15, 2007 at 11:20:27AM -0700, Darren Spruell wrote:
>
>
>>On 1/15/07, Alexander Bochmann <[EMAIL PROTECTED]> wrote:
>>
>>
>>>...on Thu, Jan 11, 2007 at 08:42:35AM +0100, Marc Balmer wrote:
>>>
>>>
>>>
hmm, why are people so proud of their uptimes when it only show they
don't care for their systems?


>>>Bah, uptimes (is it that time of the year again?)...
>>>
>>>Last login: Sun Jan  7 19:22:19 2007 from xxx
>>>OpenBSD 2.3 (LOCAL) #0: Wed Jul 31 12:51:38 CEST 2002
>>>
>>>Welcome to OpenBSD: The proactively secure Unix-like operating system.
>>>
>>>{104} ls -al /etc/localtime
>>>lrwxr-xr-x  1 root  wheel  33 Jun 12  1998 /etc/localtime ->
>>>/usr/share/zoneinfo/Europe/Berlin
>>>
>>>That's an Internet-connected system, running mail, web, DNS.
>>>
>>>
>>Do you sleep well at night exposing that system to the Internet? One
>>would question the amount of effort to ensure patch application (if at
>>all possible) on a system so far out of date...
>>
>>
>
>If you are careful, and know what you do, and know what software to run,
>you can get away with a very small number of patches.
>
>Still, I do try to upgrade at least once a year.
>
>   Joachim
>
>
>
and behind a good firewall, even old systems like RH6 with a million
holes are never going to get exploited as long as you take proper care.
in a high volume, public facing infrastructure.  there are too many
cpanel and IIS servers around to hack, trying to bust into an OBSD box
would mean you have to be a real hacker, like U4EA or DFENS or Radikahl
or Sidewinder or Tkiller or Datarape or  One's looking for a car
with the doors unlocked, engine running, keys in the ignition, owner
nowhere in sight.

Can you show me some 3.6 exploits Alexander?  It's hard to doubt someone
cares about their system when they hang out on the list.  Perhaps
really, they actually know what they are doing eh?

Where would I get an exploit for 3.6?, which exploit would I choose?
Remote?  How many hundreds of those are lying about for ready download?
   Can you or anyone else we know on the list give a nice howto on this?

Just how easy is it compared to the old days when you could run nuke.c
on IRC chats and literally shut down someone's Mac Plus on them
mid-sentence?  Now that was fun.  Wasn't even a web back then, just
BITNET, majordomo, FTPlists, BB's, archie, WAIS, even encrypted chat
/dcc_chat /dcc_send (where'd that go?)

I have a 3.6 system right here, unpatched behind a firewall, and one not
behind a firewall.  -i'd like to see some skills from the
fear-uncertainty-doubt 5th column since everyone's so absolutely sure
you'll get hacked if you turn on a computer at all and try to make it do
anything useful whatsoever.

uptime 412 days on #drgori  he's running an ancient os because informix
hasn't altogether disappeared from the base of code run by our v1 app
made what, 6 years ago?  boy if that one customer who needs it would
just scram.  -practical need vs. non-useful-perfectionism.  the ugly
flower never gets picked.  I hate informix, but #drgori never goes
down, does it's job, and even though people try, -they just can't get
through the defenses in front of him.

Just curious Alexander.  Just curious.

booya.  biff y

-krb





--
--
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)



Re: ahem... skype on o'bsd

2006-12-11 Thread Olivier Meyer
Right:

Skype is completely closed source, and the developers have admitted that the
only reason it is not open source, is because the security is too weak. See
http://www.theregister.co.uk/2004/06/15/voip_and_skype/page3.html
and look at the bottom:
"Would he[Niklas Zennstrom, co-founder of Skype] make Skype open-source? No
- that would make its strong 1024 bit encryption and security vulnerable:
"We could do it but only if we re-engineered the way it works and we don't
have the time right now."
This is merely security by obscurity. According to a security analysis
presented at BlackHat, the code is protected with many layers of obfuscation
and encryption, intended to prevent reversing.
Here is relevant sections of the EULA(
http://www.skype.com/company/legal/eula/):

4.1 *Utilization of Your computer.* You hereby acknowledge that the Skype
Software may utilize the processor and bandwidth of the computer (or other
applicable device) You are utilizing, for the limited purpose of
facilitating the communication between Skype Software users.

So, basically, you accept the fact that Skype will use any and all resources
to "facilitate communication". How does anyone know that there is not a
backdoor that can bes used to access any machine running Skype.

On 12/11/06, Tobias Weisserth <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On Dec 11, 2006, at 6:15 PM, Vim Visual wrote:
>
> > the proof ;)
> >
> > http://www.aei.mpg.de/~pau/skype.png
> >
> > I don't have any contacts under that nickname; therefore the list
> > is empty...
>
> I would be careful with Skype. My father's Mandriva Linux PC was
> trojaned using an outdated version of Skype as entry point.
>
> Maybe you should post a systrace policy along with how to use Skype
> in OpenBSD ;-)
>
> regards,
> Tobias W.
>
>


-- 
"If I am laughing, check your backups."



Re: Software License

2006-11-29 Thread Olivier Meyer

Any other operating system
would need (must) download only the *.o object code and clue them together.

I agree, that you "clue" object files together.
Maybe someone else needs to be clued.
--
---
Olivier V. Meyer
Congress shall make no law respecting an establishment of religion, or
prohibiting the free exercise thereof; or abridging the freedom of
speech, or of the press; or the right of the people peaceably to
assemble, and to petition the government for a redress of grievances.



Re: ktrace interpretation

2006-11-21 Thread Olivier Meyer

Most of what you see is the libc setting up default signal stuff.
After the ELF is loaded mprotect is used to make the area executable,
so when EIP is set to the starting point, the program does not SEGV.

As to understanding, I would read the appropriate code in the kernel.

On 11/21/06, Jan Stary <[EMAIL PROTECTED]> wrote:

Hi all,

being interested in the system's internals, I ktraced a trivial 'program':

int
main(void)
{
return 0;
}

cc -o prog prog.c
strip prog
ktrace ./prog
kdump -f ktrace.out

The output shows things one would expect: ktrace execve's the ./prog,
libc.so is read, permisions are checked, the executable itself is read,
...


  9465 ktrace   RET   ktrace 0
  9465 ktrace   CALL  execve(0xcfbf6be7,0xcfbf6a58,0xcfbf6a60)
  9465 ktrace   NAMI  "./prog"
  9465 prog NAMI  "/usr/libexec/ld.so"
  9465 prog EMUL  "native"
  9465 prog RET   execve 0
  9465 prog CALL  issetugid()
  9465 prog RET   issetugid 0
  9465 prog CALL  mprotect(0x2506,0x1000,0x1)
  9465 prog RET   mprotect 0
  9465 prog CALL  mmap(0,0x1000,0x3,0x1002,0x,0,0,0)
  9465 prog RET   mmap -2113363968/0x8208a000
  9465 prog CALL  open(0x2505e723,0,0)
  9465 prog NAMI  "/var/run/ld.so.hints"
  9465 prog RET   open 3
  9465 prog CALL  fstat(0x3,0xcfbcbb40)
  9465 prog RET   fstat 0
  9465 prog CALL  mmap(0,0x2e4f,0x1,0x2,0x3,0,0,0)
  9465 prog RET   mmap 2129707008/0x7ef0c000
  9465 prog CALL  close(0x3)
  9465 prog RET   close 0
  9465 prog CALL  open(0x7ef0da80,0,0)
  9465 prog NAMI  "/usr/lib/libc.so.39.0"
  9465 prog RET   open 3
  9465 prog CALL  fstat(0x3,0xcfbcaff0)
  9465 prog RET   fstat 0
  9465 prog CALL  read(0x3,0xcfbcb060,0x1000)
  9465 prog GIO   fd 3 read 4088 bytes
   "\^?ELF\^A\^A\^A\0\0\0\0\0\0\0\0\0\^C\0\^C\0\^A\0\0\0\M-(:\^A\0004\0\0\
\0\^TA:\0\0\0\0\0004\0 \0\^F\0(\0)\0&\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
[...]
  9465 prog GIO   fd 3 read 8 bytes
   "\0\0\0\0\M-1\^E\0\0"
  9465 prog RET   read 4096/0x1000

Then comes stuff I don't really understand -

  9465 prog CALL  mquery(0,0x82000,0x5,0,0x3,0,0,0)
  9465 prog RET   mquery 217501696/0xcf6d000
  9465 prog CALL  mquery(0x2cf6d000,0xd000,0x1,0x10,0x,0,0,0)
  9465 prog RET   mquery 754372608/0x2cf6d000
  9465 prog CALL  mquery(0x2cf7a000,0x3000,0x3,0x10,0x,0,0,0)
  9465 prog RET   mquery 754425856/0x2cf7a000
  9465 prog CALL  mquery(0x2cf7d000,0x2000,0x3,0x10,0x,0,0,0)
  9465 prog RET   mquery 754438144/0x2cf7d000
  9465 prog CALL  mquery(0x2cf7f000,0x1000,0x3,0x10,0x,0,0,0)
  9465 prog RET   mquery 754446336/0x2cf7f000
  9465 prog CALL  mquery(0x2cf8,0x1e000,0x3,0x10,0x,0,0,0)
  9465 prog RET   mquery 754450432/0x2cf8
  9465 prog CALL  mmap(0xcf6d000,0x82000,0x5,0x12,0x3,0,0,0)
  9465 prog RET   mmap 217501696/0xcf6d000
  9465 prog CALL  mmap(0x2cf6d000,0xd000,0x1,0x12,0x3,0,0x82000,0)
  9465 prog RET   mmap 754372608/0x2cf6d000
  9465 prog CALL  mmap(0x2cf7a000,0x3000,0x3,0x12,0x3,0,0x8f000,0)
  9465 prog RET   mmap 754425856/0x2cf7a000
  9465 prog CALL  mmap(0x2cf7d000,0x2000,0x3,0x12,0x3,0,0x91000,0)
  9465 prog RET   mmap 754438144/0x2cf7d000
  9465 prog CALL  mmap(0x2cf7f000,0x1000,0x3,0x12,0x3,0,0x92000,0)
  9465 prog RET   mmap 754446336/0x2cf7f000
  9465 prog CALL  mmap(0x2cf8,0x1e000,0x3,0x1012,0x,0,0,0)
  9465 prog RET   mmap 754450432/0x2cf8
  9465 prog CALL  close(0x3)
  9465 prog RET   close 0

- is this the ELF being loaded into memory?

  9465 prog CALL  mmap(0,0x5000,0x3,0x1002,0x,0,0,0)
  9465 prog RET   mmap -2099654656/0x82d9d000
  9465 prog CALL  mprotect(0xcf6d000,0x81d56,0x7)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0x2cf6d000,0xc3a1,0x3)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0xcf6d000,0x81d56,0x5)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0x2cf6d000,0xc3a1,0x1)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0xcf6d000,0x81d56,0x7)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0x2cf6d000,0xc3a1,0x3)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0xcf6d000,0x81d56,0x5)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0x2cf6d000,0xc3a1,0x1)
  9465 prog RET   mprotect 0
  9465 prog CALL  mprotect(0x2cf7d000,0x2000,0x1)
  9465 prog RET   mprotect 0
  9465 prog CALL  munmap(0x82d9d000,0x5000)
  9465 prog RET   munmap 0
  9465 prog CALL  mprotect(0x3c002000,0x1000,0x1)
  9465 prog RET   mprotect 0

- and then being "protected" in the memory, whatever that means?

What puzles me most is the subsequent storm of sigprocmask():
what are these really for? Who is really doing this - my prog
doesn't really chagnge its sigset.

  9465 prog CALL  sigpr