Enclave

During my early levels of computer scienceyness, I happened upon a quest that lead me to take AP Computer Science from Biga. Biga is unconventional. Your grade was a cloud, until you got the answers right, or were properly able to convey your understanding. Yes, you could actually present the wrong answer to the question at hand but demonstrate your understanding of the material and be fine. It was fun. Naturally, some parents were not pleased with this methodology of teaching. Somehow they came to the conclusion that the lack of a grade somehow meant the XP was poor. Little did they know.

I had eighth hour APCS with five other friends. It was a small group, which meant it was very focused. I remember hand waving on the whiteboard every sort using a dozen or so magnets with numbers on them, and creating a sweet Roman numeral fractional calculator. It was my introduction to C++ as a language, which, to date is still my favorite language to program in. I got the opportunity to come back and talk to a class about my experiences as a CS major. It just so happened that Biga was getting rid of the text book I had learned from as they were moving to Java *shakes fist*, so I totally picked that up!1.

I am often reminded, at work, of one of the more memorable sections, okay, the only section of the book I remember. It had a number of programming rules. One is particular has stuck with me to this day, though I often forget which number it is. Lucky for me I have this book to tell me things. Book, tell me what the fifth rule of programming is. Book? Damnit book.

Never be afraid to chuck it all and start over, especially at the design stage. If your organization is a mess, patching it generally will produce a patched-up mess, at best.

Rule number five is a concept that people have a hard time following through with. After all, once you have done all that work, you can’t just really scrap it all, can you? It’s, well, your precious. And you don’t want to just go chuck it into lava. If Minecraft has taught us anything, it’s there’s no coming back from lava. But sadly, the precious is created from evil, and <bleep!?> gotta go. There becomes a point where you are dealing with such a poorly designed program flow, that trying to maintain, improve, or even use it is such a time sink that you are literally throwing time away, into lava. Twice.

(more…)

Introductions Are In Order

Sometimes at work I have the need to get distracted. You can only work on the some programs so much before you just want to tear it to little bits and start it over from scratch (programming rule #4). So in order to combat this impulse I find little side programs I can create that I can somewhat realistically say is work related. That’s my story and I’m sticking to it! This one involves an experiment in the wonderful language of Python. It’s a fun language, in my opinion. Very powerful and flexible. It takes a little bit of getting used to, but it’s my scripting language of choice. But watch out, it’s pooooiisssoonnous.

We were using Apache Solr on a project (which I lurve) but had some constraints adjusting the log level. We’d typically see a gig or so a day of log traffic that we really didn’t need. Solr uses SLF4J logging. It’s a handy packing that abstracts the logging calls, and you instead provide another library that has the actual implementation. AFAIK there is only JDK and Log4j implementations, but I haven’t really looked. By default, the logging library provided is JDK which is all well and good. JDK logging relies on the container to control what is being logged and where. The problem was, we use Weblogic Not that I have a whole lot against Weblogic, but in order to hook into its logging mechanism, the implementation needs to extend the commons logging API that Weblogic provides. We could have gone Log4j, but didn’t really have the bandwidth to spare. Or more acurately, since the project was being transitioned off, we didn’t have the ability to make code changes.

Enter the python (it’s like a baby dragon or something). Solr comes with a very nice logging console where, at runtime, you can tweak log levels. It only affects JDK logging (conveniently) and gets reset with a server bounce (which happens regularly). So I came up with the program concept to use a script set these levels somehow. I took a look at the server, and lo and behold (for fun go look up the definition of lo) there was a python staring right at me. So I told my co-workers to move slowly, they’re not poisonous, but can constrict you to death with powerful squeezes. After a few turns, and a lucky critical, we took care of the python. I returned to my search and found that the server had python installed and available for use. I had my language of choice and started looking at what I could do. The result? A pretty nifty command line utility that can submit a Web form with parameters of your own design. It’s so good, it has almost completely overflowed the good and rolled over to evil. Luckily we use unsigned values here. Take that evil!

(more…)

A long time ago, in a galaxy far far away … the datasources were under attack by the visitors across the 8th dimension. Thanks to our plucky hero, Buckaroo Banzai, we were able to advert total disaster at the hands of Zinglon and his endless level of Beer … I mean what?

In reference to my earlier blog about Weblogic datasources (check it out, it is made of win) I have a short blurb that Weblogic’s implementation seems incomplete. Well, it still is (it still does not appear to correctly identify the the deployed application nor module in that one error message), but as of 10.3.2 there is a database flag that quite succinctly solves the problem.

I can’t quite find the documentation at the moment. I imagine it is on Metalink. My system admin found this handy startup flag. Add the argument to the server start arguments for each managed server (adding it to just one seemed to work okay; I didn’t really try to break it but I soooo should).

That’s all there is to it. Attempting to access the datasource returns a nice error message stating remote access is disabled. Seems easy. Almost too easy. So easy that they should make it a freaking setting on the datasource or managed server. But I’m not bitter.

Future topic along these lines, locking down the JNDI tree in general (cause it needs it, unless you like someone binding a few thousand values to your tree). By the way, if you can guess all the references in paragraph one, you get a cookie. No foolin’.

The Problem

While going about a routine hey, what’s that do at work, we discovered that, by default, Weblogic is configured to allow remote access to all JNDI resources. These resources include JDBC datasources. Datasources are defined to connect to a database as a specific user (this can be a proxy user, but not necessarily). What this means, is some intelligent person could gain access to the datasources configured on a Weblogic server and have all the powers allowed by the user defined in that datasource. This takes various levels of knowledge to be able to gain the correct host and port, and to be able to pass the right SQL to perform malicious operations. However difficult it may be, it is still a possibility.

With that in mind, Weblogic does provide a way to lock this down via security constraints. In fact, you can lock down many resources via these security policies which appear to be pretty open by default. However, enabling constraints can cause problems. Stack traces like the following can appear:

This presents us with the heart of the problem, how do we go about limiting access to these datasources and still allow the applications we maintain to function.

(more…)