We said we would roll out articles about our (Rails) Content Management System project and this is one of the very first, exposing our difficulties and decisions about deploying an usable, yet fancy charting functionality.

We won’t spoil the surprise about the name of the project, yet.

The Quest

Finding a free, open source and (if possible) BSD or LGPL licensed library implementing chart and graphing functionality. We want to avoid licensing hell as much as we want to avoid bloated interfaces that obscure the statistical data more than abstracting it properly.

Requirements

1. Capable of displaying technically complex data sets.
2. Good performance: it must escalate well! (as much as we designed our product to do so).
   1. Efficient cache and server-side solution or browser supported implementation (ie. SVG based).
3. Non-bloated, elegant code: we want to modify it and understand what’s going on.
4. Usable, simplistic interface (API): we hate working with an over complicated API.
5. Nice, fancy, yet-not overly design-ish graphs:
   1. Experience shows that complicated graphs do nothing to improve the visibility of statistical data: better divide by many, than squeeze many in a few.
   2. Simple graphs and clean shapes are far more smooth and pleasing to the eye (Isn’t the whole rounded corner spice about this anyway?).
   3. The more complex the data-set, the more simple a graph should be. The density of data displayed will be high and adding unnecessary fuss will just get in way of interpreting it properly.
6. Non-hosted solution: we can’t afford the risk of exposing customer or sensitive information to external hosts and services. We could do exceptions for publicly obtained data, but definitely not the internal information.

Continue reading →

Yahoo! released yesterday a new version of the feature-rich, BSD licensed YUI (the Yahoo! User Interface library) implementing several improvements, some new controls and other innovative functionality. The components that quickly turned heads over here, are namely:

• The charts control: finally we get those infamous pie charts for free (requires Flash like most of the web chart and graphing tools, but its quality is certainly higher than some of the competitors)
• Improved performance for the rich text editor: apparently now you can select its components in a fine-grained manner, avoiding load of unnecessary functions
• New fanciness for the button control…
• Hell of a load of fixes, ranging from browser specific issues and compatibility changes

Their change-log contains a complete overview of the fixes and the new features. We are integrating this new release for the (Ruby on Rails powered) content management system engine we have developed for our corporate site, and recommend YUI for any serious web developer seeking a library providing solid controls and functionality. Besides, it comes with no strings attached

Make sure you have read the first part of this article already!

From the XNU 9.0 source code, we have some interesting snippets around:

         /* load_machfile() maps the vnode */
         (void)ubc_map(imgp->ip_vp, PROT_READ | PROT_EXEC);

 #ifdef notyet
 /* Hmm .. */
 #if defined(VM_PROT_READ_IS_EXEC)
                 if (prot & VM_PROT_READ)
                         prot |= VM_PROT_EXECUTE;
                 if (maxprot & VM_PROT_READ)
                         maxprot |= VM_PROT_EXECUTE;
 #endif
 #endif /* notyet */

 #if 3777787
                 if (prot & (VM_PROT_EXECUTE | VM_PROT_WRITE))
                         prot |= VM_PROT_READ;
                 if (maxprot & (VM_PROT_EXECUTE | VM_PROT_WRITE))
                         maxprot |= VM_PROT_READ;
 #endif  /* radar 3777787 */

Pay attention to the VM_PROT_EXECUTE flag. Let’s get back to the exploit development: we have reliable EIP control and we can most probably make use of return to libSystem (good old ret2libc) or jump into heap. But Leopard randomizes some library addresses… Let’s see how the process memory layout looks like for Quicktime:

(gdb) shell vmmap 18909 | grep MALLOC
MALLOC (freed?)        00122000-00123000 [    4K] rw-/rwx SM=COW
MALLOC_LARGE           00124000-0012a000 [   24K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           0012d000-0012e000 [    4K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           00135000-0013e000 [   36K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_TINY            00200000-00300000 [ 1024K] rw-/rwx SM=COW  DefaultMallocZone_0x200000
MALLOC_LARGE           003bf000-003ca000 [   44K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           003f9000-00401000 [   32K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           00405000-00406000 [    4K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           0042f000-00459000 [  168K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_LARGE           007ee000-007f7000 [   36K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_SMALL           00800000-01000000 [ 8192K] rw-/rwx SM=COW  DefaultMallocZone_0x200000
MALLOC_LARGE           1450f000-14517000 [   32K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC_TINY            14900000-14a00000 [ 1024K] rw-/rwx SM=COW  DefaultMallocZone_0x200000
MALLOC_LARGE           15d1d000-15d27000 [   40K] rw-/rwx SM=PRV  DefaultMallocZone_0x200000
MALLOC                  [   10.4M]

Continue reading →

A new vulnerability has been published for Apple’s Quicktime software. It definitely looks like an easy one: a classic stack-based buffer overflow. We started testing the original proof of concept against Mac OS X 10.5.1 (9B18) (that’s Leopard!)…

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000004141416b
Crashed Thread:  0

It’s possibly embarrassing for a high profile application to have this kind of issues (it’s 2007 already, approaching 2008…), but they are found everywhere. Apple is really trying to make advances in security matters, even if they didn’t manage to implement some of them properly for Leopard.

After some tinkering, we started developing our own multi-platform exploit. This vulnerability, like most plain simple stack-based buffer overflows, allows full register control, therefore code execution is a piece of cake (the register status below comes from running the original Python code, available from Milw0rm):

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x41414141  ebx: 0x166a36f0  ecx: 0x00000000  edx: 0x00000041
  edi: 0xbfffd308  esi: 0x6875683f  ebp: 0xbfffd438  esp: 0xbfffd180
   ss: 0x0000001f  efl: 0x00010207  eip: 0x166a41c5   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x4141416b

Nowadays, it’s a common practice to release rather incomplete and non-reliable exploits or so-called “proof of concept” code (although, people out there don’t agree on naming conventions; an exploit is not a proof of concept, if it’s really reliable). They are usually coded in Python (we don’t really know what’s so great about it as a language for exploit development, Ruby is possibly much more flexible and efficient for such purposes), have poor indentation and code style, use publicly available shellcode and repetitive techniques, and last but not least, they are poorly automated. Releasing a proof of concept nowadays is generally a matter of getting those nifty 15 minutes of fame. Then it vanishes…

Continue reading →

Finally we decided that Mephisto wasn’t yet the right solution for us, and until we have time to develop a proper blog engine in place, we are going to keep this going. We are damn busy at the moment, hence why our time for blogging is really limited. But we’ll try to keep interesting news around, stay tuned .

We are sorry about the not-so impressive looking current design, but this is being worked on behind the scenes. Hopefully the design guy will come up with some fresh ideas, he’s still busy working on the corporate site. Although, developing with Rails is never boring (well, just unlikely ).